From: Vlastimil Babka <vbabka@suse.cz>
To: Laura Abbott <labbott@redhat.com>, Jan Kara <jack@suse.cz>,
Balbir Singh <bsingharora@gmail.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org,
Peter Zijlstra <peterz@infradead.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [Lsf-pc] [LSF/MM ATTEND] 2016: Requests to attend MM-summit
Date: Wed, 27 Jan 2016 20:07:56 +0100 [thread overview]
Message-ID: <56A9158C.60604@suse.cz> (raw)
In-Reply-To: <56A2725B.1090509@redhat.com>
On 01/22/2016 07:18 PM, Laura Abbott wrote:
> On 01/22/2016 06:19 AM, Jan Kara wrote:
>> On Fri 22-01-16 20:17:07, Balbir Singh wrote:
>>> On Fri, 22 Jan 2016 10:11:12 +0530
>>> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>>>
>>>
>>> +1
>>>
>>> I agree CMA design is a concern. I also noticed that today all CMA pages come
>>> from one node. On a NUMA box you'll see cross traffic going to that region -
>>> although from kernel only text. It should be discussed at the summit and Aneesh
>>> would be a good representative
>>
>> I'm not really an mm guy but CMA has been discussed already last year, and
>> I think even the year before... Are we moving somewhere? So if this is
>> about hashing out what blocks VM_PINNED series (I think it may be just a
>> lack of Peter's persistence in pushing it ;) then that looks like a
>> sensible goal. Some other CMA architecture discussions need IMHO a more
>> concrete proposals...
>>
>> Honza
>>
>
> The conclusion from the CMA session last year was that pinned pages need to be
> fixed up at the caller sites doing the pinning. Each caller site really needs
> to be taken individually. I think the discussion last year was good but if
> it's going to end up with a different conclusion I agree there needs to be
> concrete proposals.
>
> Something that could be worth discussing as well is Joonsoo Kim's proposal for
> page reference tracking http://thread.gmane.org/gmane.linux.kernel.api/16138
I think indentifying the pinners and actually doing something about them, are
different things. The tracking might help with the identification. Maybe some
pins can be removed as found to be unneeded, but VM_PINNED infrastructure should
help with dealing with the genuine ones - IIRC the idea was that prior to
(relatively long-term) pinning, the pages would be migrated away from MOVABLE or
CMA pageblocks to reduce fragmentation/allow CMA allocations succeed. Otherwise
the only other option I see for genuine long-term pins is to pre-emptively
allocate such pages as UNMOVABLE. A waste in case it's a large class of pages
where only a subset of them (not known upfront) is going to be pinned. What if
the class is e.g. "userspace-mapped pages"?
> Thanks,
> Laura
>
> --
> 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>
>
--
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>
next prev parent reply other threads:[~2016-01-27 19:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 4:41 Aneesh Kumar K.V
2016-01-22 9:17 ` Balbir Singh
2016-01-22 14:19 ` [Lsf-pc] " Jan Kara
2016-01-22 18:18 ` Laura Abbott
2016-01-27 19:07 ` Vlastimil Babka [this message]
2016-01-28 9:33 ` Aneesh Kumar K.V
2016-01-22 16:38 ` Johannes Weiner
2016-01-25 7:08 ` Joonsoo Kim
2016-01-25 23:37 ` Laura Abbott
2016-01-26 7:38 ` Joonsoo Kim
2016-01-26 18:53 ` Vlastimil Babka
2016-01-28 9:43 ` Aneesh Kumar K.V
2016-01-27 18:32 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A9158C.60604@suse.cz \
--to=vbabka@suse.cz \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--cc=labbott@redhat.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox