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

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

[Aneesh Kumar K.V]

Hi,

I would like to attend LSF/MM this year (2016).

My main interest is in MM related topics although I am also interested
in the btrfs status discussion (particularly related to subpage size block
size topic), if we are having one. Most of my recent work in the kernel is
related to adding ppc64 support for different MM features. My current focus
is on adding Linux support for the new radix MMU model of Power9.

Topics of interest include:

* CMA allocator issues:
  (1) order zero allocation failures:
      We are observing order zero non-movable allocation failures in kernel
with CMA configured. We don't start a reclaim because our free memory check
does not consider free_cma. Hence the reclaim code assume we have enough free
pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
like to discuss the challenges in getting this merged upstream.
https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)

Others needed for the discussion:
Joonsoo Kim <iamjoonsoo.kim@lge.com>

  (2) CMA allocation failures due to pinned pages in the region:
      We allow only movable allocation from the CMA region to enable us
to migrate those pages later when we get a CMA allocation request. But
if we pin those movable pages, we will fail the migration which can result
in CMA allocation failure. One such report can be found here.
http://article.gmane.org/gmane.linux.kernel.mm/136738

Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would
like to discuss what needs to be done to get this patch series merged upstream
https://lkml.org/lkml/2014/5/26/345 (VM_PINNED)

Others needed for the discussion:
Peter Zijlstra <peterz@infradead.org>

* Improvements to tlb flush
    Archiectures like ppc64 can do range based tlb flush and for that we need
to know the page size used to map the virtual address range. I would like
to discuss changes to mmu gather and tlb flush api that will help in efficient
implementation of tlb flush for ppc64.
   (1) MMU gather improvements
       https://github.com/kvaneesh/linux/commit/215b9c7c03bb8d742349e2aefaadcf8cc0c04dd8
       https://github.com/kvaneesh/linux/commit/43bd9e91a841bbc9e3c6ee56a4d12ed00019718c
   (2) different APIs to flush hugepage tlb mappings.
       https://github.com/kvaneesh/linux/commit/b8a78933fea93cb0b2978868e59a0a4b12eb92eb
       https://github.com/kvaneesh/linux/commit/049d361a59a3342c2ce5a4feae61dce4974af226

NOTE: I haven't posted these changes yet to the list because of dependent patches getting reviewed. But should
have them available on the list before LSF/MM.

* HMM status (Heterogeneous Memory Management)

  I would like to discuss the roadblocks w.r.t merging HMM patchset upstream.
http://article.gmane.org/gmane.linux.kernel.mm/140229

Others needed for the discussion:
Jérôme Glisse <jglisse@redhat.com>

-aneesh

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

[Balbir Singh]

On Fri, 22 Jan 2016 10:11:12 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> Hi,
> 
> I would like to attend LSF/MM this year (2016).
> 
> My main interest is in MM related topics although I am also interested
> in the btrfs status discussion (particularly related to subpage size block
> size topic), if we are having one. Most of my recent work in the kernel is
> related to adding ppc64 support for different MM features. My current focus
> is on adding Linux support for the new radix MMU model of Power9.
> 
> Topics of interest include:
> 
> * CMA allocator issues:
>   (1) order zero allocation failures:
>       We are observing order zero non-movable allocation failures in kernel
> with CMA configured. We don't start a reclaim because our free memory check
> does not consider free_cma. Hence the reclaim code assume we have enough free
> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
> like to discuss the challenges in getting this merged upstream.
> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
> 
> Others needed for the discussion:
> Joonsoo Kim <iamjoonsoo.kim@lge.com>
> 
>   (2) CMA allocation failures due to pinned pages in the region:
>       We allow only movable allocation from the CMA region to enable us
> to migrate those pages later when we get a CMA allocation request. But
> if we pin those movable pages, we will fail the migration which can result
> in CMA allocation failure. One such report can be found here.
> http://article.gmane.org/gmane.linux.kernel.mm/136738
> 
> Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would
> like to discuss what needs to be done to get this patch series merged upstream
> https://lkml.org/lkml/2014/5/26/345 (VM_PINNED)
> 
> Others needed for the discussion:
> Peter Zijlstra <peterz@infradead.org>

+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

Balbir Singh.

--
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-pc] [LSF/MM ATTEND] 2016: Requests to attend MM-summit

[Jan Kara]

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:
> 
> > Hi,
> > 
> > I would like to attend LSF/MM this year (2016).
> > 
> > My main interest is in MM related topics although I am also interested
> > in the btrfs status discussion (particularly related to subpage size block
> > size topic), if we are having one. Most of my recent work in the kernel is
> > related to adding ppc64 support for different MM features. My current focus
> > is on adding Linux support for the new radix MMU model of Power9.
> > 
> > Topics of interest include:
> > 
> > * CMA allocator issues:
> >   (1) order zero allocation failures:
> >       We are observing order zero non-movable allocation failures in kernel
> > with CMA configured. We don't start a reclaim because our free memory check
> > does not consider free_cma. Hence the reclaim code assume we have enough free
> > pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
> > like to discuss the challenges in getting this merged upstream.
> > https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
> > 
> > Others needed for the discussion:
> > Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > 
> >   (2) CMA allocation failures due to pinned pages in the region:
> >       We allow only movable allocation from the CMA region to enable us
> > to migrate those pages later when we get a CMA allocation request. But
> > if we pin those movable pages, we will fail the migration which can result
> > in CMA allocation failure. One such report can be found here.
> > http://article.gmane.org/gmane.linux.kernel.mm/136738
> > 
> > Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would
> > like to discuss what needs to be done to get this patch series merged upstream
> > https://lkml.org/lkml/2014/5/26/345 (VM_PINNED)
> > 
> > Others needed for the discussion:
> > Peter Zijlstra <peterz@infradead.org>
> 
> +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
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Johannes Weiner]

Hi,

On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote:
> * CMA allocator issues:
>   (1) order zero allocation failures:
>       We are observing order zero non-movable allocation failures in kernel
> with CMA configured. We don't start a reclaim because our free memory check
> does not consider free_cma. Hence the reclaim code assume we have enough free
> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
> like to discuss the challenges in getting this merged upstream.
> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)

The exclusion of cma pages from the watermark checks means that
reclaim is happening too early, not too late, which leaves memory
underutilized. That's what ZONE_CMA set out to fix.

But unmovable allocations can still fail when the only free memory is
inside CMA regions. I don't see how ZONE_CMA would fix that.

CC Joonsoo

But as Jan said, we discussed ZONE_CMA before, so it's not clear
whether rehashing it without new data points would be too useful.

> Others needed for the discussion:
> Joonsoo Kim <iamjoonsoo.kim@lge.com>
> 
>   (2) CMA allocation failures due to pinned pages in the region:
>       We allow only movable allocation from the CMA region to enable us
> to migrate those pages later when we get a CMA allocation request. But
> if we pin those movable pages, we will fail the migration which can result
> in CMA allocation failure. One such report can be found here.
> http://article.gmane.org/gmane.linux.kernel.mm/136738
> 
> Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would
> like to discuss what needs to be done to get this patch series merged upstream
> https://lkml.org/lkml/2014/5/26/345 (VM_PINNED)
> 
> Others needed for the discussion:
> Peter Zijlstra <peterz@infradead.org>

There was no consensus whether this specific implementation would work
well for all sources of pinning. Giving this some time in the MM track
could be useful.

CC Peter

--
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-pc] [LSF/MM ATTEND] 2016: Requests to attend MM-summit

[Laura Abbott]

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:
>>
>>> Hi,
>>>
>>> I would like to attend LSF/MM this year (2016).
>>>
>>> My main interest is in MM related topics although I am also interested
>>> in the btrfs status discussion (particularly related to subpage size block
>>> size topic), if we are having one. Most of my recent work in the kernel is
>>> related to adding ppc64 support for different MM features. My current focus
>>> is on adding Linux support for the new radix MMU model of Power9.
>>>
>>> Topics of interest include:
>>>
>>> * CMA allocator issues:
>>>    (1) order zero allocation failures:
>>>        We are observing order zero non-movable allocation failures in kernel
>>> with CMA configured. We don't start a reclaim because our free memory check
>>> does not consider free_cma. Hence the reclaim code assume we have enough free
>>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
>>> like to discuss the challenges in getting this merged upstream.
>>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
>>>
>>> Others needed for the discussion:
>>> Joonsoo Kim <iamjoonsoo.kim@lge.com>
>>>
>>>    (2) CMA allocation failures due to pinned pages in the region:
>>>        We allow only movable allocation from the CMA region to enable us
>>> to migrate those pages later when we get a CMA allocation request. But
>>> if we pin those movable pages, we will fail the migration which can result
>>> in CMA allocation failure. One such report can be found here.
>>> http://article.gmane.org/gmane.linux.kernel.mm/136738
>>>
>>> Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would
>>> like to discuss what needs to be done to get this patch series merged upstream
>>> https://lkml.org/lkml/2014/5/26/345 (VM_PINNED)
>>>
>>> Others needed for the discussion:
>>> Peter Zijlstra <peterz@infradead.org>
>>
>> +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

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>

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

[Joonsoo Kim]

Hello,

2016-01-23 1:38 GMT+09:00 Johannes Weiner <hannes@cmpxchg.org>:
> Hi,
>
> On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote:
>> * CMA allocator issues:
>>   (1) order zero allocation failures:
>>       We are observing order zero non-movable allocation failures in kernel
>> with CMA configured. We don't start a reclaim because our free memory check
>> does not consider free_cma. Hence the reclaim code assume we have enough free
>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
>> like to discuss the challenges in getting this merged upstream.
>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)

As far as I know, there is no disagreement on this patchset in last year LSF/MM.
Problem may be due to my laziness... Sorry about that. I will handle it soon.
Is there anything more that you concern?

> The exclusion of cma pages from the watermark checks means that
> reclaim is happening too early, not too late, which leaves memory
> underutilized. That's what ZONE_CMA set out to fix.
>
> But unmovable allocations can still fail when the only free memory is
> inside CMA regions. I don't see how ZONE_CMA would fix that.
>
> CC Joonsoo

I understand what Aneesh's problem is.

Assume that

X = non movable free page
Y = movable free page
Z = cma free page

X < min watermark
X + Y > high watermark
Z > high watermark

If there are bunch of consecutive movable allocation requests,
Y will decrease. After some time, Y will be exhausted. At that
time, there is enough Z so movable allocation request still can be
handled in fastpath and kswapd isn't waked up. In that situation,
if atomic non-movable page allocation for order-0 comes,
it would be failed.

Although it isn't mentioned on ZONE_CMA patchset, it is also
fixed by that patchset because with that patchset, all CMA pages
are in CMA zone so freepage calculation is always precise.

Thanks.

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

[Laura Abbott]

On 01/24/2016 11:08 PM, Joonsoo Kim wrote:
> Hello,
>
> 2016-01-23 1:38 GMT+09:00 Johannes Weiner <hannes@cmpxchg.org>:
>> Hi,
>>
>> On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote:
>>> * CMA allocator issues:
>>>    (1) order zero allocation failures:
>>>        We are observing order zero non-movable allocation failures in kernel
>>> with CMA configured. We don't start a reclaim because our free memory check
>>> does not consider free_cma. Hence the reclaim code assume we have enough free
>>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
>>> like to discuss the challenges in getting this merged upstream.
>>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
>
> As far as I know, there is no disagreement on this patchset in last year LSF/MM.
> Problem may be due to my laziness... Sorry about that. I will handle it soon.
> Is there anything more that you concern?
>

Is that series going to conflict with the work done for ZONE_DEVICE or run
into similar problems?
033fbae988fcb67e5077203512181890848b8e90 (mm: ZONE_DEVICE for "device memory")
has commit text about running out of ZONE_SHIFT bits and needing to get
rid of ZONE_DMA instead so it seems like ZONE_CMA would run into the same
problem.

Thanks,
Laura
  
>> The exclusion of cma pages from the watermark checks means that
>> reclaim is happening too early, not too late, which leaves memory
>> underutilized. That's what ZONE_CMA set out to fix.
>>
>> But unmovable allocations can still fail when the only free memory is
>> inside CMA regions. I don't see how ZONE_CMA would fix that.
>>
>> CC Joonsoo
>
> I understand what Aneesh's problem is.
>
> Assume that
>
> X = non movable free page
> Y = movable free page
> Z = cma free page
>
> X < min watermark
> X + Y > high watermark
> Z > high watermark
>
> If there are bunch of consecutive movable allocation requests,
> Y will decrease. After some time, Y will be exhausted. At that
> time, there is enough Z so movable allocation request still can be
> handled in fastpath and kswapd isn't waked up. In that situation,
> if atomic non-movable page allocation for order-0 comes,
> it would be failed.
>
> Although it isn't mentioned on ZONE_CMA patchset, it is also
> fixed by that patchset because with that patchset, all CMA pages
> are in CMA zone so freepage calculation is always precise.
>
> Thanks.
>
> --
> 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>

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

[Joonsoo Kim]

On Mon, Jan 25, 2016 at 03:37:06PM -0800, Laura Abbott wrote:
> On 01/24/2016 11:08 PM, Joonsoo Kim wrote:
> >Hello,
> >
> >2016-01-23 1:38 GMT+09:00 Johannes Weiner <hannes@cmpxchg.org>:
> >>Hi,
> >>
> >>On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote:
> >>>* CMA allocator issues:
> >>>   (1) order zero allocation failures:
> >>>       We are observing order zero non-movable allocation failures in kernel
> >>>with CMA configured. We don't start a reclaim because our free memory check
> >>>does not consider free_cma. Hence the reclaim code assume we have enough free
> >>>pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
> >>>like to discuss the challenges in getting this merged upstream.
> >>>https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
> >
> >As far as I know, there is no disagreement on this patchset in last year LSF/MM.
> >Problem may be due to my laziness... Sorry about that. I will handle it soon.
> >Is there anything more that you concern?
> >
> 
> Is that series going to conflict with the work done for ZONE_DEVICE or run
> into similar problems?
> 033fbae988fcb67e5077203512181890848b8e90 (mm: ZONE_DEVICE for "device memory")
> has commit text about running out of ZONE_SHIFT bits and needing to get
> rid of ZONE_DMA instead so it seems like ZONE_CMA would run into the same
> problem.

Hmm... I'm not sure. I need a investigation. What I did before is
enlarging section size. Then, number of section is reduced and we need
less section bit in struct page's flag. This worked for my sparsemem
configuration but I'm not sure other conguration. Perhaps, in other
congifuration, we can limit node bits and max number of node.

Thanks.

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

[Vlastimil Babka]

On 26.1.2016 8:38, Joonsoo Kim wrote:
> On Mon, Jan 25, 2016 at 03:37:06PM -0800, Laura Abbott wrote:
>>
>> Is that series going to conflict with the work done for ZONE_DEVICE or run
>> into similar problems?
>> 033fbae988fcb67e5077203512181890848b8e90 (mm: ZONE_DEVICE for "device memory")
>> has commit text about running out of ZONE_SHIFT bits and needing to get
>> rid of ZONE_DMA instead so it seems like ZONE_CMA would run into the same
>> problem.
> 
> Hmm... I'm not sure. I need a investigation. What I did before is
> enlarging section size. Then, number of section is reduced and we need
> less section bit in struct page's flag. This worked for my sparsemem
> configuration but I'm not sure other conguration. Perhaps, in other
> congifuration, we can limit node bits and max number of node.

This seems to be a solution proposed for the ZONE_DMA and ZONE_DEVICE
coexistence https://lkml.org/lkml/2016/1/25/1233
It wouldn't help with ZONE_CMA, so I guess it's time to look for a more robust one.

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

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

[Peter Zijlstra]

On Fri, Jan 22, 2016 at 11:38:01AM -0500, Johannes Weiner wrote:
> > 
> > Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would
> > like to discuss what needs to be done to get this patch series merged upstream
> > https://lkml.org/lkml/2014/5/26/345 (VM_PINNED)
> > 
> > Others needed for the discussion:
> > Peter Zijlstra <peterz@infradead.org>
> 
> There was no consensus whether this specific implementation would work
> well for all sources of pinning. Giving this some time in the MM track
> could be useful.

I got stuck and lost in IB land. But that was a fair while ago. I should
probably look at rebasing it against something recent, although I
seriuosly doubt I can get through IB this 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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Vlastimil Babka]

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>

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

[Aneesh Kumar K.V]

Laura Abbott <labbott@redhat.com> writes:

> 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:
>>>
>>>> Hi,
>>>>
>>>> I would like to attend LSF/MM this year (2016).
>>>>
>>>> My main interest is in MM related topics although I am also interested
>>>> in the btrfs status discussion (particularly related to subpage size block
>>>> size topic), if we are having one. Most of my recent work in the kernel is
>>>> related to adding ppc64 support for different MM features. My current focus
>>>> is on adding Linux support for the new radix MMU model of Power9.
>>>>
>>>> Topics of interest include:
>>>>
>>>> * CMA allocator issues:
>>>>    (1) order zero allocation failures:
>>>>        We are observing order zero non-movable allocation failures in kernel
>>>> with CMA configured. We don't start a reclaim because our free memory check
>>>> does not consider free_cma. Hence the reclaim code assume we have enough free
>>>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
>>>> like to discuss the challenges in getting this merged upstream.
>>>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
>>>>
>>>> Others needed for the discussion:
>>>> Joonsoo Kim <iamjoonsoo.kim@lge.com>
>>>>
>>>>    (2) CMA allocation failures due to pinned pages in the region:
>>>>        We allow only movable allocation from the CMA region to enable us
>>>> to migrate those pages later when we get a CMA allocation request. But
>>>> if we pin those movable pages, we will fail the migration which can result
>>>> in CMA allocation failure. One such report can be found here.
>>>> http://article.gmane.org/gmane.linux.kernel.mm/136738
>>>>
>>>> Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would
>>>> like to discuss what needs to be done to get this patch series merged upstream
>>>> https://lkml.org/lkml/2014/5/26/345 (VM_PINNED)
>>>>
>>>> Others needed for the discussion:
>>>> Peter Zijlstra <peterz@infradead.org>
>>>
>>> +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.

But that was not what was suggested in the kvm guest ram pin due to vfio
thread I linked above. I think we still need to have an agreement on
whether the callers should be migrating the pages or a generic framework
like VM_PINNED is needed.

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

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

[Aneesh Kumar K.V]

Joonsoo Kim <js1304@gmail.com> writes:

> Hello,
>
> 2016-01-23 1:38 GMT+09:00 Johannes Weiner <hannes@cmpxchg.org>:
>> Hi,
>>
>> On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote:
>>> * CMA allocator issues:
>>>   (1) order zero allocation failures:
>>>       We are observing order zero non-movable allocation failures in kernel
>>> with CMA configured. We don't start a reclaim because our free memory check
>>> does not consider free_cma. Hence the reclaim code assume we have enough free
>>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
>>> like to discuss the challenges in getting this merged upstream.
>>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
>
> As far as I know, there is no disagreement on this patchset in last year LSF/MM.
> Problem may be due to my laziness... Sorry about that. I will handle it soon.
> Is there anything more that you concern?
>
>> The exclusion of cma pages from the watermark checks means that
>> reclaim is happening too early, not too late, which leaves memory
>> underutilized. That's what ZONE_CMA set out to fix.
>>
>> But unmovable allocations can still fail when the only free memory is
>> inside CMA regions. I don't see how ZONE_CMA would fix that.
>>
>> CC Joonsoo
>
> I understand what Aneesh's problem is.
>
> Assume that
>
> X = non movable free page
> Y = movable free page
> Z = cma free page
>
> X < min watermark
> X + Y > high watermark
> Z > high watermark
>
> If there are bunch of consecutive movable allocation requests,
> Y will decrease. After some time, Y will be exhausted. At that
> time, there is enough Z so movable allocation request still can be
> handled in fastpath and kswapd isn't waked up. In that situation,
> if atomic non-movable page allocation for order-0 comes,
> it would be failed.
>
> Although it isn't mentioned on ZONE_CMA patchset, it is also
> fixed by that patchset because with that patchset, all CMA pages
> are in CMA zone so freepage calculation is always precise.
>

That is the issue I am hitting and if we don't have any blocker against
ZONE_CMA then we can drop this topic.

-aneesh

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

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>

[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

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