LSF/MM 2016: Call for Proposals

LSF/MM 2016: Call for Proposals

[Martin K. Petersen]

The annual Linux Storage, Filesystem and Memory Management Summit for
2016 will be held on April 18th and 19th at the Raleigh Marriott City
center, Raleigh, NC.

Like last year, LSF/MM will be colocated with the Linux Foundation Vault
conference which takes place on April 20th and 21st in the same
venue. For those that do not know, Vault is designed to be an event
where open source storage and filesystem practitioners meet storage
implementors and, as such, it would be of benefit for LSF/MM attendees
to attend.

	http://events.linuxfoundation.org/events/linux-storage-filesystem-and-mm-summit
	http://events.linuxfoundation.org/events/vault

On behalf of the committee I am issuing a call for agenda proposals that
are suitable for cross-track discussion as well as technical subjects
for the breakout sessions.

1) Proposals for agenda topics should be sent before February 29th, 2016
to:

	lsf-pc@lists.linux-foundation.org

and cc the Linux list or lists that are relevant for the topic in
question:

	ATA:	linux-ide@vger.kernel.org
	Block:	linux-block@vger.kernel.org
	FS:	linux-fsdevel@vger.kernel.org
	MM:	linux-mm@kvack.org
	SCSI:	linux-scsi@vger.kernel.org

If advance notice is required for visa applications then please send
proposals before February 11th. The committee will complete the first
round of selections near that date to accommodate applications.

Please tag your proposal with [LSF/MM TOPIC] to make it easier to
track. In addition, please make sure to start a new thread for each
topic rather than following up to an existing one.

Agenda topics and attendees will be selected by the program committee,
but the final agenda will be formed by consensus of the attendees at the
summit.

We will try to cap attendance at around 25-30 per track to facilitate
discussions, although the final numbers will depend on the room sizes at
the venue.

2) Requests to attend the summit should be sent to:

	lsf-pc@lists.linux-foundation.org

Please summarise what expertise you will bring to the meeting, and what
you would like to discuss. Please also tag your email with [LSF/MM
ATTEND] so there is less chance of it getting lost.

Presentations are allowed to guide discussion, but are strongly
discouraged. There will be no recording or audio bridge. However, we
expect that written minutes will be published as we did in previous
years

2015:
	https://lwn.net/Articles/lsfmm2015/

2014:
	http://lwn.net/Articles/LSFMM2014/

2013:
	http://lwn.net/Articles/548089/

3) If you have feedback on last year's meeting that we can use to
improve this year's, please also send that to:

	lsf-pc@lists.linux-foundation.org

Thank you on behalf of the program committee:

Storage:
	Jens Axboe (track chair)
	James Bottomley
	Christoph Hellwig
	Martin K. Petersen (program chair)

Filesystems:
	Josef Bacik
	Jan Kara
	Jeff Layton (track chair)
	Anna Schumaker
	Theodore Ts'o
	Ric Wheeler

MM:
	Mel Gorman
	Johannes Weiner
	Rik van Riel (track chair)

-- 
Martin K. Petersen	Oracle Linux Engineering

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[LSF/MM ATTEND] 2016: Requests to attend MM-summit

[Jesper Dangaard Brouer]

On Tue, 12 Jan 2016 11:05:45 -0500 "Martin K. Petersen" <martin.petersen@oracle.com> wrote:

> The annual Linux Storage, Filesystem and Memory Management Summit for
> 2016 will be held on April 18th and 19th at the Raleigh Marriott City
> center, Raleigh, NC.
> 
[...]
> 
> 2) Requests to attend the summit should be sent to:
> 
> 	lsf-pc@lists.linux-foundation.org
> 
> Please summarise what expertise you will bring to the meeting, and what
> you would like to discuss. Please also tag your email with [LSF/MM
> ATTEND] so there is less chance of it getting lost.

Hi committee,

I would like to participate in LSF/MM.  

I've over the last year optimized the SLAB+SLUB allocators,
specifically by introducing a bulking API.  This work is almost
complete, but I have some more ideas in the MM-area that I would like
to discuss with people.

Specifically I have the following ideas:

1. Speedup *SLUB* with approx 10-20% by using per CPU detached
   freelists for all types of allocations/free.
 * Actually have a prove-of-concept implementation that showed 20% speedup
 * Idea is every page (used-by SLUB) gets a detached freelist
 * The first CPU that alloc the page, owns this detached freelist
 * CPU owning page can do sync free operation on this freelist.
 * SLUB is already highly biased to keep objects on same CPU

2. Bulk alloc without disabling IRQ (SLUB)
 * This is something Real-Time (RT) people will be screaming for,
   once more users of bulk API starts to appear.
 * I think it is doable, but also very challenging to keep performance

3. Faster memset clearing of memory in SLUB
 * Currently netstack clears SKBs right after alloc (2-3% in perf)
 * In SLUB allocator we could clear larger section of memory
   which is significantly faster.
 * Bulk alloc would be the right spot
 * Difficult part is inventing an algorithm for matching contiguous mem,
   which is fast-enough, as the est. time budget is 15-20 cycles.

4. Bulk free from RCU context
 * One major slowdown of using RCU free is, that free will always hit
   SLUB slowpath.  We could change this via bulk free API.
 * This would be a major benefit for the entire kernel performance.
 * The challenge here is getting to know the RCU free code well-enough

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit

[Christoph Lameter]

On Fri, 15 Jan 2016, Jesper Dangaard Brouer wrote:

> I've over the last year optimized the SLAB+SLUB allocators,
> specifically by introducing a bulking API.  This work is almost
> complete, but I have some more ideas in the MM-area that I would like
> to discuss with people.

I think this is pretty good work which can help a lot for subsystems
dealing with large amounts of objects. Given that network speeds and
memory increases we may have to look increasingly at bulk allocation to
make further strides in MM performance by rewriting subsystems to take
advantage of these features.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>