LSF/MM summit deadline on Sunday

Hi everyone,

Just a reminder that if you'd like to attend the LSF/MM summit on April 1-2, the deadline to apply is February 5th at the end of this week. See below for more details.

If you did not already do so, please send [LSF/MM TOPIC] suggestions, or request to [ATTEND], to [email protected]

Invitations will go out next week: so if you send a TOPIC or ATTEND mail now, you should expect confirmation next week - numbers permitting. We shall probably be unable to fulfil late requests to attend.

Thank you, and hope to see you soon :).
Andrea, Hugh, Mel

----- Forwarded message from Andrea Arcangeli <[email protected]> -----

Date: Wed, 21 Dec 2011 15:43:48 +0100
From: Andrea Arcangeli <[email protected]>
To: [email protected]
Subject: [CFP] Linux Storage, Filesystem & Memory Management Summit 2012 (April 1-2)

The annual Linux Storage, Filesystem and Memory Management Summit for 2012 will be held on the 2 days preceding the Linux Foundation Collaboration Summit at Hotel Nikko in San Francisco, CA:

https://events.linuxfoundation.org/events/lsfmm-summit
https://events.linuxfoundation.org/events/collaboration-summit/

We'd therefore like to issue a call for agenda proposals that are suitable for cross-track discussion as well as more technical subjects for discussion in the breakout sessions.

1) Suggestions for agenda topics should be sent before February 5th 2012 to:

[email protected]

and optionally cc the Linux list which would be most interested in it:

SCSI: [email protected]
FS: [email protected]
MM: [email protected]

Please remember to tag your subject with [LSF/MM TOPIC] to make it easier to track. Agenda topics and attendees will be selected by the programme committee, but the final agenda will be formed by consensus of the attendees on the day.

We'll 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 should be sent to:

[email protected]

please summarize what expertise you will bring to the meeting, and what you'd like to discuss. please also tag your email with [ATTEND] so there's less chance of it getting lost in the large mail pile.

Presentations are allowed to guide discussion, but are strongly discouraged. There will be no recording or audio bridge, however written minutes will be published as in previous years:

2011:

http://lwn.net/Articles/436871/
http://lwn.net/Articles/437066/

2010:
http://lwn.net/Articles/399148/
http://lwn.net/Articles/399313/
http://lwn.net/Articles/400589/

2009:
http://lwn.net/Articles/327601/
http://lwn.net/Articles/327740/
http://lwn.net/Articles/328347/

Prior years:
http://www.usenix.org/events/lsf08/tech/lsf08sums.pdf
http://www.usenix.org/publications/login/2007-06/openpdfs/lsf07sums.pdf

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

[email protected]

Thank you on behalf of the Program Committee:

Storage

Jens Axboe
James Bottomley
Vivek Goyal
Dan Williams

Filesystems

Trond Myklebust
Chris Mason
Christoph Hellwig
Theodore Ts'o
Mingming Cao
Jan Kara
Joel Becker

MM

Andrea Arcangeli
Hugh Dickins
Mel Gorman

----- End forwarded message -----

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

I don't see it proposed as a topic yet (unless I missed it) but I spoke with Peter briefly and I think this would be a good opportunity in particular to discuss NUMA-aware load-balancing. Currently, we only try to solve the 1-d problem of optimizing for weight; but there's recently been interest from several parties in improving this. Issues involves proactively accounting for the distribution of current allocations, determining when to initiate reactive migration (or when not to move tasks!), and the associated grouping semantics.

Thanks,

- Paul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi Paul,

Thanks for the topic proposal. We actually planned to have two topics slots for the NUMA aware balancing. It was also proposed as a topic by Andi and Peter but they didn't CC linux-mm on it so it wasn't visible yet.

BTW, not sure if you noticed I also got AutoNUMA to work pretty well over the last month. I posted the results and testcases used for the benchmarks on linux-kernel. I'm still cleaning it up. I've yet to do full evaluation in virt mixed environment though (for host it seems to work as good as hard bindings so far, especially in the testcases I developed to test it which starts from worst case memory placement scenarios). It tracks both mm<->processes affinity and page<->thread affinity and balances processes vs processes and threads vs threads in the scheduler (while still maxing out all idle CPUs of course). Shared memory accessed by different nodes is handled with some heuristic. By default I only allow CPU_IDLE/NEWIDLE load balances across the nodes as that performs best globally :) but tends to partition the NUMA system more so it's less fair. I'll add a tweak to allow load_balances also for non idle CPUs across nodes (it's a few liner change to switch between the two modes), but even in that case it always tries to find an affine task first (double the number of passes). Overall there's an huge room for improvement in the scheduler area, and the way I hooked into the scheduler to drive it in function of the NUMA statistical info, is quite self contained but probably not the best for long term (though at runtime I shouldn't matter, so I leave it for a second stage cleanup if these algorithms will be proven to be worthwhile).

Thanks,
Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

So this would mean having statistics that show how many pages are allocated on each node and take that into consideration for load balancing? Which is something that we felt to be desirable for a long time.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi,

Correct.

The most difficult part after collecting the per page thread affinity and per-mm (process) thread affinity, is to compute it and drive both scheduler and migrate.c in function of it. The algorithm I got seems to work but it's not easy stuff. But at least it's not intrusive, it's trivial to proof absolutely zero change of runtime behavior the moment the core daemon that drives the whole thing stops running (sysfs disable or not compiled in).

There are still areas where this logic needs improvement (like migrating unmapped pagecache when node is full etc..).

I'm trying to clean things up so the code will be more readable and tunable at runtime. I also need to reduce its cost when you boot the kernel on a not-numa machine (allocating the data on the pgdat instead of struct page, which is not so easy with all memory models we got that allocate the pgdat data in different places, and allocate autonuma structures pointed by mm and task struct). All structures are embedded static right now (not allocated dynamically) but making it dynamic is not difficult cleanup even it's not the top priority at the moment.

The only difficult feature I still miss is native THP migration which I plan to add after complete sysfs tuning works. (khugepaged is already capable to recreate THP on destination node, but I don't like that because the migration right now leads to temporary creation of sptes instead of sticking to spmds on KVM, not to tell a lot more vmexits than if we only get one for the spmd). For no-virt probably it's not so important feature as the hugepages are recreated later and a page fault costs less than a vmexit.

Thanks,
Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>