On Mon 09-01-17 06:31:50, Eric Dumazet wrote:
> On Mon, Jan 9, 2017 at 1:58 AM, Michal Hocko wrote:
>
> >
> > Also this seems to be an init code so I assume a modprobe would have to
> > set a non-default policy to make use of it. Does anybody do that out
> > there?
>
> This is not init code. Who
On Mon, Jan 9, 2017 at 1:58 AM, Michal Hocko wrote:
>
> Also this seems to be an init code so I assume a modprobe would have to
> set a non-default policy to make use of it. Does anybody do that out
> there?
This is not init code. Whole point of rhashtable is that the resizes
can happen anytime.
On Sat 07-01-17 10:37:41, Eric Dumazet wrote:
> On Sat, Jan 7, 2017 at 1:27 AM, Michal Hocko wrote:
> > On Fri 06-01-17 14:14:49, Eric Dumazet wrote:
>
> >> I believe the intent was to get NUMA spreading, a bit like what we have
> >> in alloc_large_system_hash() when hashdist == HASHDIST_DEFAULT
On Sat, Jan 7, 2017 at 1:27 AM, Michal Hocko wrote:
> On Fri 06-01-17 14:14:49, Eric Dumazet wrote:
>> I believe the intent was to get NUMA spreading, a bit like what we have
>> in alloc_large_system_hash() when hashdist == HASHDIST_DEFAULT
>
> Hmm, I am not sure this works as expected then. Beca
On Fri 06-01-17 14:14:49, Eric Dumazet wrote:
> On Fri, 2017-01-06 at 13:16 +0100, Michal Hocko wrote:
> > I was thinking about the rhashtable which was the source of the c&p and
> > it can be simplified as well.
> > ---
> > From 43604f5f020284ea85d928d52f6a55fde7ca Mon Sep 17 00:00:00 2001
> >
On Fri, 2017-01-06 at 13:16 +0100, Michal Hocko wrote:
> I was thinking about the rhashtable which was the source of the c&p and
> it can be simplified as well.
> ---
> From 43604f5f020284ea85d928d52f6a55fde7ca Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Fri, 6 Jan 2017 13:12:31 +010
I was thinking about the rhashtable which was the source of the c&p and
it can be simplified as well.
---
>From 43604f5f020284ea85d928d52f6a55fde7ca Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Fri, 6 Jan 2017 13:12:31 +0100
Subject: [PATCH] rhashtable: simplify a strange allocation patte
On Fri 06-01-17 10:51:15, Michal Hocko wrote:
> Hi Tom,
> I am currently looking at kmalloc with vmalloc fallback users [1]
> and came across alloc_ila_locks which is using a pretty unusual
> allocation pattern - it seems to be a c&p alloc_bucket_locks which
> is doing a similar thing - except it h
Hi Tom,
I am currently looking at kmalloc with vmalloc fallback users [1]
and came across alloc_ila_locks which is using a pretty unusual
allocation pattern - it seems to be a c&p alloc_bucket_locks which
is doing a similar thing - except it has to support GFP_ATOMIC.
I am really wondering what is
9 matches
Mail list logo
