From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
Date: Tue, 24 Apr 2012 13:30:05 -0300 [thread overview]
Message-ID: <4F96D50D.4020804@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1204241120130.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On 04/24/2012 01:24 PM, Christoph Lameter wrote:
> On Tue, 24 Apr 2012, Glauber Costa wrote:
>
>>> Would this not also be a good case to introduce static branching?
>>>
>>> number_of_cpusets is used to avoid going through unnecessary processing
>>> should there be no cpusets in use.
>>
>> static branches comes with a set of problems themselves, so I usually prefer
>> to use them only in places where we don't want to pay even a cache miss if we
>> can avoid, or a function call, or anything like that - like the slub cache
>> alloc as you may have seen in my kmem memcg series.
>>
>> It doesn't seem to be the case here.
>
> How did you figure that? number_of_cpusets was introduced exactly because
> the functions are used in places where we do not pay the cost of calling
> __cpuset_node_allowed_soft/hardwall. Have a look at these. They may take
> locks etc etc in critical allocation paths
I am not arguing that.
You want to avoid the cost of processing a function, that's fair.
(Note that by "function call cost" I don't mean the cost of processing a
function, but the cost of a (potentially empty) function call.)
The real question is: Are you okay with the cost of a branch + a global
variable (which is almost read only) fetch?
The test of a global variable can - and do as of right now - avoid all
the expensive operations like locking, sleeping, etc, and if you don't
need to squeeze every nanosecond you can, they are often simpler - and
therefore better - than static branching.
Just to mention one point I am coming across these days - that initiated
all this: static patching holds the cpu_hotplug.lock. So it can't be
called if you hold any lock that has been already held under the
cpu_hotplug.lock. This will probably mean any lock the cpuset cgroup
needs to take, because it is called - and to do a lot of things - from
the cpu hotplug handler, that holds the cpu_hotplug.lock.
So if if were a case of simple static branch usage, I am not opposed to
it. But I foresee it getting so complicated, that a global variable
seems to do the job we need just fine.
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
<devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
Date: Tue, 24 Apr 2012 13:30:05 -0300 [thread overview]
Message-ID: <4F96D50D.4020804@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1204241120130.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On 04/24/2012 01:24 PM, Christoph Lameter wrote:
> On Tue, 24 Apr 2012, Glauber Costa wrote:
>
>>> Would this not also be a good case to introduce static branching?
>>>
>>> number_of_cpusets is used to avoid going through unnecessary processing
>>> should there be no cpusets in use.
>>
>> static branches comes with a set of problems themselves, so I usually prefer
>> to use them only in places where we don't want to pay even a cache miss if we
>> can avoid, or a function call, or anything like that - like the slub cache
>> alloc as you may have seen in my kmem memcg series.
>>
>> It doesn't seem to be the case here.
>
> How did you figure that? number_of_cpusets was introduced exactly because
> the functions are used in places where we do not pay the cost of calling
> __cpuset_node_allowed_soft/hardwall. Have a look at these. They may take
> locks etc etc in critical allocation paths
I am not arguing that.
You want to avoid the cost of processing a function, that's fair.
(Note that by "function call cost" I don't mean the cost of processing a
function, but the cost of a (potentially empty) function call.)
The real question is: Are you okay with the cost of a branch + a global
variable (which is almost read only) fetch?
The test of a global variable can - and do as of right now - avoid all
the expensive operations like locking, sleeping, etc, and if you don't
need to squeeze every nanosecond you can, they are often simpler - and
therefore better - than static branching.
Just to mention one point I am coming across these days - that initiated
all this: static patching holds the cpu_hotplug.lock. So it can't be
called if you hold any lock that has been already held under the
cpu_hotplug.lock. This will probably mean any lock the cpuset cgroup
needs to take, because it is called - and to do a lot of things - from
the cpu hotplug handler, that holds the cpu_hotplug.lock.
So if if were a case of simple static branch usage, I am not opposed to
it. But I foresee it getting so complicated, that a global variable
seems to do the job we need just fine.
next prev parent reply other threads:[~2012-04-24 16:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 19:37 [PATCH v2 0/5] Fix problem with static_key decrement Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-23 19:37 ` [PATCH v2 1/5] don't attach a task to a dead cgroup Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:20 ` KAMEZAWA Hiroyuki
2012-04-23 19:37 ` [PATCH v2 2/5] blkcg: protect blkcg->policy_list Glauber Costa
2012-04-23 19:37 ` Glauber Costa
2012-04-23 19:37 ` [PATCH v2 3/5] change number_of_cpusets to an atomic Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:25 ` KAMEZAWA Hiroyuki
2012-04-24 15:02 ` Christoph Lameter
[not found] ` <alpine.DEB.2.00.1204241001050.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2012-04-24 16:15 ` Glauber Costa
2012-04-24 16:15 ` Glauber Costa
[not found] ` <4F96D1A8.6040604-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 16:24 ` Christoph Lameter
[not found] ` <alpine.DEB.2.00.1204241120130.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2012-04-24 16:30 ` Glauber Costa [this message]
2012-04-24 16:30 ` Glauber Costa
[not found] ` <4F96D50D.4020804-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 18:27 ` Christoph Lameter
2012-04-23 19:37 ` [PATCH v2 4/5] don't take cgroup_mutex in destroy() Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:31 ` KAMEZAWA Hiroyuki
[not found] ` <4F96109A.8000907-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-04-24 11:42 ` Glauber Costa
2012-04-24 11:42 ` Glauber Costa
[not found] ` <4F9691A8.1070106-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-25 8:01 ` Li Zefan
2012-04-23 19:37 ` [PATCH v2 5/5] decrement static keys on real destroy time Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-6-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:40 ` KAMEZAWA Hiroyuki
[not found] ` <4F9612B9.7050705-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-04-24 11:41 ` Glauber Costa
2012-04-24 11:41 ` Glauber Costa
2012-04-25 0:22 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F96D50D.4020804@parallels.com \
--to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.