Date: Thu, 04 Oct 2007 12:25:26 -0700 From: Julian Elischer <julian@elischer.org> To: Attilio Rao <attilio@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, Alfred Perlstein <alfred@freebsd.org>, hackers@freebsd.org Subject: Re: Critical Sections for userland. Message-ID: <47053E26.1020309@elischer.org> In-Reply-To: <3bbf2fe10710041054x1c580bb2m892bf389a70c0e6c@mail.gmail.com> References: <20071003015231.GJ31826@elvis.mu.org> <Pine.GSO.4.64.0710022244250.626@sea.ntplx.net> <20071003025418.GN31826@elvis.mu.org> <3bbf2fe10710041054x1c580bb2m892bf389a70c0e6c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Attilio Rao wrote: > 2007/10/3, Alfred Perlstein <alfred@freebsd.org>: >> * Daniel Eischen <deischen@freebsd.org> [071002 19:46] wrote: >>> On Tue, 2 Oct 2007, Alfred Perlstein wrote: >>> >>>> Hi guys, we need critical sections for userland here. >>>> >>>> This is basically to avoid a process being switched out while holding >>>> a user level spinlock. >>> Setting the scheduling class to real-time and using SCHED_FIFO >>> and adjusting the thread priority around the lock doesn't work? >> Too heavy weight, we want to basically have this sort of code >> in userland: >> >> /* assume single threaded process for now */ >> static int is_critical; >> >> >> >> atomic_mutex_lock(); /* implies ++is_critical */ >> ...do stuff... >> atomic_mutex_unlock(); /* implies --is_critical */ >> >> We don't want two or more syscalls per lock operation. :) > > Basically, preemption in kernelspace is handled by using the > td_critnest counter which should work in this way: > - critical_enter() bumps td_critnest > - if preemption is required or an ipi arrives and the operation is > signalled with the td_owepreempt flag and will be deferred. > - once critical_exit() is called the counter is decreased. If > necessary (checking for td_critnest and td_owepreempt) the preemptive > operation happens instantanely. > > It is all very fast and highly scalable as scope of operation is > entirely per-thread so it doesn't require any lock. I think maybe you > should use a very similar scheme to this. > > Attilio > > I suggest that we map a per-thread page into the address space if it requests it. (and a per process page). The scheduler could look at it for behavioural hints when it is present. there are ways this could be done. it sort of dovetails into work other people have been considering..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47053E26.1020309>