Hello, Tahsin.
On Mon, Feb 27, 2017 at 12:37:59PM -0800, Tahsin Erdogan wrote:
> > Ah, absolutely, that's a stupid failure but we should be able to fix
> > that by making the blkg functions take gfp mask and allocate
> > accordingly, right? It'll probably take preallocation tricks because
> > of
Hello,
On Mon, Feb 27, 2017 at 05:00:31AM -0800, Tahsin Erdogan wrote:
> On Mon, Feb 27, 2017 at 1:52 AM, Michal Hocko wrote:
> > On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote:
> >> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of
> >> a failure is higher than GFP_KERNEL cas
On Mon, Feb 27, 2017 at 01:12:11PM -0800, Tahsin Erdogan wrote:
> That makes sense. I will work a patch that does that (unless you are
> interested in implementing it yourself).
I'd really appreciate if you can work on it. Thanks a lot!
--
tejun
>> Doing preallocations would probably work but not sure if that can be
>> done without
>> complicating code too much. Could you describe what you have in mind?
>
> So, blkg_create() already takes @new_blkg argument which is the
> preallocated blkg and used during q init. Wouldn't it work to make
On Mon, Feb 27, 2017 at 12:29 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Feb 27, 2017 at 12:27:08PM -0800, Tahsin Erdogan wrote:
>> A better example is the call path below:
>>
>> pcpu_alloc+0x68f/0x710
>> __alloc_percpu_gfp+0xd/0x10
>> __percpu_counter_init+0x55/0xc0
>> cfq_pd_alloc+0x3b2/0x4e0
>>
Hello,
On Mon, Feb 27, 2017 at 12:27:08PM -0800, Tahsin Erdogan wrote:
> A better example is the call path below:
>
> pcpu_alloc+0x68f/0x710
> __alloc_percpu_gfp+0xd/0x10
> __percpu_counter_init+0x55/0xc0
> cfq_pd_alloc+0x3b2/0x4e0
> blkg_alloc+0x187/0x230
> blkg_create+0x489/0x670
> blkg_lookup_
Hi Tejun,
On Mon, Feb 27, 2017 at 11:51 AM, Tejun Heo wrote:
>> __vmalloc+0x45/0x50
>> pcpu_mem_zalloc+0x50/0x80
>> pcpu_populate_chunk+0x3b/0x380
>> pcpu_alloc+0x588/0x6e0
>> __alloc_percpu_gfp+0xd/0x10
>> __percpu_counter_init+0x55/0xc0
>> blkg_alloc+0x76/0x230
>> blkg_create+0x489/0x670
>> blk
On Mon 27-02-17 11:32:50, Tahsin Erdogan wrote:
> >> >
> >> > Yes, this prevents adding more pcpu chunks and so cause "atomic"
> >> > allocations
> >> > to fail more easily.
> >>
> >> Then I fail to see what is the problem you are trying to fix.
> >
> > To be more specific. Could you describe what
>> >
>> > Yes, this prevents adding more pcpu chunks and so cause "atomic"
>> > allocations
>> > to fail more easily.
>>
>> Then I fail to see what is the problem you are trying to fix.
>
> To be more specific. Could you describe what more can we do in the
> vmalloc layer for GFP_NOWAIT allocation
On Mon 27-02-17 18:07:53, Michal Hocko wrote:
> On Mon 27-02-17 09:01:09, Tahsin Erdogan wrote:
> > On Mon, Feb 27, 2017 at 7:25 AM, Michal Hocko wrote:
> > > /*
> > > * No space left. Create a new chunk. We don't want multiple
> > > * tasks to create chunks simultaneou
On Mon 27-02-17 09:01:09, Tahsin Erdogan wrote:
> On Mon, Feb 27, 2017 at 7:25 AM, Michal Hocko wrote:
> > /*
> > * No space left. Create a new chunk. We don't want multiple
> > * tasks to create chunks simultaneously. Serialize and create iff
> > * there's st
On Mon, Feb 27, 2017 at 7:25 AM, Michal Hocko wrote:
> /*
> * No space left. Create a new chunk. We don't want multiple
> * tasks to create chunks simultaneously. Serialize and create iff
> * there's still no empty chunk after grabbing the mutex.
> */
On Mon 27-02-17 05:00:31, Tahsin Erdogan wrote:
> On Mon, Feb 27, 2017 at 1:52 AM, Michal Hocko wrote:
> > On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote:
> >> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of
> >> a failure is higher than GFP_KERNEL case. This is mainly becaus
On Mon, Feb 27, 2017 at 1:52 AM, Michal Hocko wrote:
> On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote:
>> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of
>> a failure is higher than GFP_KERNEL case. This is mainly because
>> pcpu_alloc() relies on previously allocated reserve
On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote:
> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of
> a failure is higher than GFP_KERNEL case. This is mainly because
> pcpu_alloc() relies on previously allocated reserves and does not make
> an effort to add memory to its pools
When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of
a failure is higher than GFP_KERNEL case. This is mainly because
pcpu_alloc() relies on previously allocated reserves and does not make
an effort to add memory to its pools for non-GFP_KERNEL case.
This issue is somewhat mitigat
16 matches
Mail list logo