[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5317B9B2.8070205@zytor.com>
Date: Wed, 05 Mar 2014 15:56:34 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Khalid Aziz <khalid.aziz@...cle.com>, David Lang <david@...g.hm>
CC: Oleg Nesterov <oleg@...hat.com>, Andi Kleen <andi@...stfloor.org>,
Thomas Gleixner <tglx@...utronix.de>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Ingo Molnar <mingo@...nel.org>, peterz@...radead.org,
akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH] Pre-emption control for userspace
On 03/05/2014 03:48 PM, Khalid Aziz wrote:
>
> Cost is writing to a memory location since thread is using mmap, not
> insignificant but hardly expensive. Thread does not need to know how
> much time it has left in current timeslice. It always sets the flag to
> request pre-emption immunity before entering the critical section and
> clears the flag when it exits its critical section. If the thread comes
> up for pre-emption while the flag is set, it gets immunity. If it does
> not, flag will be cleared at the end of critical section any way.
>
A little more than that. The scheduler needs to set *another* flag
telling the process to yield upon leaving the critical section; if the
process doesn't, the scheduler needs to keep enough accounting to know
to penalize the process, or this method will not be usable for
unprivileged processes.
I have been thinking about how to deal with the fact that if this isn't
locked in memory, what happens if it is paged out. If that can be
detected at reasonable cost, it probably makes most sense to simply say
that if the pointed-to memory is paged out, we're not in a critical section.
-hpa
--
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