[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55466E72.8060602@redhat.com>
Date: Sun, 03 May 2015 14:52:34 -0400
From: Rik van Riel <riel@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
CC: Mike Galbraith <umgwanakikbuti@...il.com>,
Ingo Molnar <mingo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>, williams@...hat.com,
Andrew Lutomirski <luto@...nel.org>, fweisbec@...hat.com,
Peter Zijlstra <peterz@...radead.org>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable
& enable from context tracking on syscall entry
On 05/03/2015 02:24 PM, Andy Lutomirski wrote:
> On Sun, May 3, 2015 at 10:30 AM, Rik van Riel <riel@...hat.com> wrote:
>> On 05/03/2015 09:23 AM, Mike Galbraith wrote:
>>
>>> Below are v4.1-rc1-172-g6c3c1eb3c35e + patches measurements.
>>>
>>> 100M * stat() on isolated cpu
>>>
>>> NO_HZ_FULL off inactive housekeeper nohz_full
>>> real 0m14.266s 0m14.367s 0m20.427s 0m27.921s
>>> user 0m1.756s 0m1.553s 0m1.976s 0m10.447s
>>> sys 0m12.508s 0m12.769s 0m18.400s 0m17.464s
>>> (real) 1.000 1.007 1.431 1.957
>> I'm convinced.
>>
>> Time to try the remote sampling of CPU use statistics, and
>> lighten up the RCU overhead of context tracking.
>>
>
> I don't understand the remote sampling proposal. Isn't the whole
> point of full nohz to avoid periodically interrupting a busy CPU? If
> what you have in mind is sending IPIs, then that's just as bad, right?
>
> If, on the other hand, you're just going to remotely sample the
> in-memory context, that sounds good.
It's the latter.
If you look at /proc/<pid>/{stack,syscall,wchan} and other files,
you will see we already have ways to determine, from in memory
content, where a program is running at a certain point in time.
In fact, the timer interrupt based accounting does a similar thing.
It has a task examine its own in-memory state to figure out what it
was doing before the timer interrupt happened.
The kernel side stack pointer is probably enough to tell us whether
a task is active in kernel space, on an irq stack, or (maybe) in user
space. Not convinced about the latter, we may need to look at the
same state the RCU code keeps track of to see what mode a task is in...
I am looking at the code to see what locks we need to grab.
I suspect the runqueue lock may be enough, to ensure that the task
struct, and stack do not go away while we are looking at them.
We cannot take the lock_trace(task) from irq context, and we probably
do not need to anyway, since we do not care about a precise stack trace
for the task.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists