LSF/MM summit deadline on Sunday

LSF/MM summit deadline on Sunday

[Andrea Arcangeli]

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 lsf-pc@lists.linux-foundation.org

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 <aarcange@redhat.com> -----

Date: Wed, 21 Dec 2011 15:43:48 +0100
From: Andrea Arcangeli <aarcange@redhat.com>
To: linux-mm@kvack.org
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:

lsf-pc@lists.linux-foundation.org

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

SCSI: linux-scsi@vger.kernel.org
FS: linux-fsdevel@vger.kernel.org
MM: linux-mm@kvack.org

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:

lsf-pc@lists.linux-foundation.org

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:

lsf-pc@lists.linux-foundation.org

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 majordomo@kvack.org.  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:"dont@kvack.org"> email@kvack.org </a>

[LSF/MM TOPIC] [ATTEND] NUMA aware load-balancing

[Paul Turner]

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

On 01/31/2012 12:28 PM, Andrea Arcangeli wrote:

> 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 lsf-pc@lists.linux-foundation.org
> 
> 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 <aarcange@redhat.com> -----
> 
> Date: Wed, 21 Dec 2011 15:43:48 +0100
> From: Andrea Arcangeli <aarcange@redhat.com>
> To: linux-mm@kvack.org
> 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:
> 
> lsf-pc@lists.linux-foundation.org
> 
> and optionally cc the Linux list which would be most interested in it:
> 
> SCSI: linux-scsi@vger.kernel.org
> FS: linux-fsdevel@vger.kernel.org
> MM: linux-mm@kvack.org
> 
> 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:
> 
> lsf-pc@lists.linux-foundation.org
> 
> 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:
> 
> lsf-pc@lists.linux-foundation.org
> 
> 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 majordomo@kvack.org.  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:"dont@kvack.org"> email@kvack.org </a>
> 


--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] NUMA aware load-balancing

[Andrea Arcangeli]

Hi Paul,

On Mon, Feb 06, 2012 at 05:15:08AM -0800, Paul Turner wrote:
> 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 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 majordomo@kvack.org.  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:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] [ATTEND] NUMA aware load-balancing

[Christoph Lameter]

On Mon, 6 Feb 2012, Paul Turner wrote:

> 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.

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 majordomo@kvack.org.  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:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] NUMA aware load-balancing

[Andrea Arcangeli]

Hi,

On Mon, Feb 06, 2012 at 10:48:42AM -0600, Christoph Lameter wrote:
> 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.

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 majordomo@kvack.org.  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:"dont@kvack.org"> email@kvack.org </a>