[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <010001692a605709-407cf476-e7b6-43be-8551-66c54059e92f-000000@email.amazonses.com>
Date: Tue, 26 Feb 2019 15:15:50 +0000
From: Christopher Lameter <cl@...ux.com>
To: "dennis@...nel.org" <dennis@...nel.org>
cc: Peng Fan <peng.fan@....com>, "tj@...nel.org" <tj@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"van.freenix@...il.com" <van.freenix@...il.com>
Subject: Re: [PATCH 2/2] percpu: km: no need to consider
pcpu_group_offsets[0]
On Mon, 25 Feb 2019, dennis@...nel.org wrote:
> > @@ -67,7 +67,7 @@ static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
> > pcpu_set_page_chunk(nth_page(pages, i), chunk);
> >
> > chunk->data = pages;
> > - chunk->base_addr = page_address(pages) - pcpu_group_offsets[0];
> > + chunk->base_addr = page_address(pages);
> >
> > spin_lock_irqsave(&pcpu_lock, flags);
> > pcpu_chunk_populated(chunk, 0, nr_pages, false);
> > --
> > 2.16.4
> >
>
> While I do think you're right, creating a chunk is not a part of the
> critical path and subtracting 0 is incredibly minor overhead. So I'd
> rather keep the code as is to maintain consistency between percpu-vm.c
> and percpu-km.c.
Well it is confusing if there the expression is there but never used. It
is clearer with the patch.
Powered by blists - more mailing lists