Requesting to share current work items

Requesting to share current work items

[Chandan Vn]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

Hi,

I would like to start contributing to linux-mm community.
Could you please let me know the current work items which I can start
working on.

Please note that I have been working on linux-mm from past 4 years but
mostly proprietary or not yet mainlined vendor codebase.

Thanks
Chandan VN

[-- Attachment #2: Type: text/html, Size: 496 bytes --]

Re: Requesting to share current work items

[Matthew Wilcox]

On Fri, Apr 06, 2018 at 07:20:47AM +0000, Chandan Vn wrote:
> Hi,
> 
> I would like to start contributing to linux-mm community.
> Could you please let me know the current work items which I can start
> working on.
> 
> Please note that I have been working on linux-mm from past 4 years but
> mostly proprietary or not yet mainlined vendor codebase.

We had a report of a problem a few weeks ago that I don't know if anybody
is looking at yet.  Perhaps you'd like to try fixing it.

The report says that, under some unidentified workload, calling vmalloc
can take many hundreds of milliseconds, and the problem is in
alloc_vmap_area().

So a good plan of work would be to devise a kernel module which can
produce a highly-fragmented vmap area, and demonstrate the problem.
Once you've got a reliable reproducer, you can look at how to fix this
problem.  We probably need a better data structure; either enhance
the existing rbtree of free areas, or change the data structure.

Re: Requesting to share current work items

[Chandan Vn]

On Sat, Apr 7, 2018 at 2:28 AM, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Apr 06, 2018 at 07:20:47AM +0000, Chandan Vn wrote:
>> Hi,
>>
>> I would like to start contributing to linux-mm community.
>> Could you please let me know the current work items which I can start
>> working on.
>>
>> Please note that I have been working on linux-mm from past 4 years but
>> mostly proprietary or not yet mainlined vendor codebase.
>
> We had a report of a problem a few weeks ago that I don't know if anybody
> is looking at yet.  Perhaps you'd like to try fixing it.
>
> The report says that, under some unidentified workload, calling vmalloc
> can take many hundreds of milliseconds, and the problem is in
> alloc_vmap_area().
>
> So a good plan of work would be to devise a kernel module which can
> produce a highly-fragmented vmap area, and demonstrate the problem.
> Once you've got a reliable reproducer, you can look at how to fix this
> problem.  We probably need a better data structure; either enhance
> the existing rbtree of free areas, or change the data structure.

Sure. I would work on this.

Re: Requesting to share current work items

[Anshuman Khandual]

On 04/07/2018 02:28 AM, Matthew Wilcox wrote:
> On Fri, Apr 06, 2018 at 07:20:47AM +0000, Chandan Vn wrote:
>> Hi,
>>
>> I would like to start contributing to linux-mm community.
>> Could you please let me know the current work items which I can start
>> working on.
>>
>> Please note that I have been working on linux-mm from past 4 years but
>> mostly proprietary or not yet mainlined vendor codebase.
> 
> We had a report of a problem a few weeks ago that I don't know if anybody
> is looking at yet.  Perhaps you'd like to try fixing it.

Do you have any reference or link to the bug report some where ?

> 
> The report says that, under some unidentified workload, calling vmalloc

Why should allocating vmap_area should depend on user space workload.
Was the workload some how causing severely fragmented vmalloc() space
making it harder for future vmalloc() requests. I am wondering.

> can take many hundreds of milliseconds, and the problem is in
> alloc_vmap_area().

Hmm, I did experiment around with a test driver on a guest with 16GB
memory. Never saw vmalloc() cost going beyond single digit milliseconds.
How many number of independent vmap_area node we are looking at in the
RB tree if we would like to hit hundreds of milliseconds in cost.

> 
> So a good plan of work would be to devise a kernel module which can
> produce a highly-fragmented vmap area, and demonstrate the problem.

I tried linear fragmentation (releasing nodes after certain distance)
and random fragmentation (releasing nodes after random distance) inside
a contiguously allocated series of vmalloc space.

> Once you've got a reliable reproducer, you can look at how to fix this
> problem.  We probably need a better data structure; either enhance
> the existing rbtree of free areas, or change the data structure.
> 

Starting node of the RB tree to search is determined with the help of
vmap_area_cache (if its applicable) followed by search in the RB tree
followed by search in the list. Wondering if in-order ascending search
inside RB tree itself will give better performance instead ? Will keep
looking into this.

Re: Requesting to share current work items

[Matthew Wilcox]

On Fri, Apr 13, 2018 at 02:45:46PM +0530, Anshuman Khandual wrote:
> On 04/07/2018 02:28 AM, Matthew Wilcox wrote:
> > On Fri, Apr 06, 2018 at 07:20:47AM +0000, Chandan Vn wrote:
> >> Hi,
> >>
> >> I would like to start contributing to linux-mm community.
> >> Could you please let me know the current work items which I can start
> >> working on.
> >>
> >> Please note that I have been working on linux-mm from past 4 years but
> >> mostly proprietary or not yet mainlined vendor codebase.
> > 
> > We had a report of a problem a few weeks ago that I don't know if anybody
> > is looking at yet.  Perhaps you'd like to try fixing it.
> 
> Do you have any reference or link to the bug report some where ?

https://marc.info/?l=linux-mm&m=151972700711879&w=2