[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ac4d495-eece-fb71-d334-a46e069b0c35@nvidia.com>
Date: Wed, 24 Mar 2021 15:01:28 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Dmitry Osipenko <digetx@...il.com>,
Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
CC: linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
<gregkh@...uxfoundation.org>, <surenb@...gle.com>,
<joaodias@...gle.com>, <willy@...radead.org>,
Colin Ian King <colin.king@...onical.com>
Subject: Re: [PATCH v7] mm: cma: support sysfs
On 3/24/21 2:31 PM, Dmitry Osipenko wrote:
> ...
>> +#include <linux/kobject.h>
>> +
>> +struct cma_kobject {
>> + struct cma *cma;
>> + struct kobject kobj;
>
> If you'll place the kobj as the first member of the struct, then
> container_of will be a no-op.
>
However, *this does not matter*. Let's not get carried away. If
container_of() ends up as a compile-time addition of +8, instead
of +0, there is not going to be a visible effect in the world.
Or do you have some perf data to the contrary?
Sometimes these kinds of things matter. But other times, they are
just pointless to fret about, and this is once such case.
thanks,
--
John Hubbard
NVIDIA
Powered by blists - more mailing lists