Re: Critical Sections for userland.
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? -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [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. :) -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [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: Well, yeah, but are you _really_ sure that you aren't just running something that should be real-time and have priority over other applications? SCHED_FIFO means you will run until you relinquish the CPU (you can only do this as root). If all your threads are well behaved, would this work? Have you tried it? Are you trying to prevent switching out of the thread amongst other threads of the same application, or all threads in the system? -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Kip Macy <[EMAIL PROTECTED]> [071002 20:00] wrote: > On 10/2/07, Alfred Perlstein <[EMAIL PROTECTED]> wrote: > > * Daniel Eischen <[EMAIL PROTECTED]> [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. :) > > > I assume these processes are running as root? There is nothing to > prevent the process from never dropping the lock. Yes there is... The part that I ommitted detailed keeping a count of the number of times this happens and if it exceeds a threshold then killing the process. Additionally, the kernel would write a byte into the user shared area indicating, "please call me because you need to yield after you're done with your critical section", if the kernel is not listened to, then we beat the process with a rusty tire iron. Sheesh, now can I get some help with this? If I wanted this kind of treatment, I'd be asking on irc! :) -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > >* Daniel Eischen <[EMAIL PROTECTED]> [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: > > Well, yeah, but are you _really_ sure that you aren't just > running something that should be real-time and have priority > over other applications? SCHED_FIFO means you will run until > you relinquish the CPU (you can only do this as root). If > all your threads are well behaved, would this work? Have > you tried it? No, because it wouldn't work. How do we know when to let go of the cpu? In my system, the kernel tells you without polling. > > Are you trying to prevent switching out of the thread > amongst other threads of the same application, or all > threads in the system? All threads on that CPU. It's basically, almost like a "soft spl" for userland. Right? -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [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: Well, yeah, but are you _really_ sure that you aren't just running something that should be real-time and have priority over other applications? SCHED_FIFO means you will run until you relinquish the CPU (you can only do this as root). If all your threads are well behaved, would this work? Have you tried it? No, because it wouldn't work. How do we know when to let go of the cpu? In my system, the kernel tells you without polling. You don't have to know when to "let go of the cpu" if your threads are well behaved (meaning they block on some event, or have periods when they wait). They will let go of the CPU normally. When they're busy, they will not be switched out (unless perhaps there is an interrupt thread that needs to run -- I'm not sure how real-time threads get scheduled against ithreads). If your threads are not well behaved (CPU hogs), then that isn't going to work because they'll probably bog down the system. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:16] wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > >* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: > >>On Tue, 2 Oct 2007, Alfred Perlstein wrote: > >> > >>>* Daniel Eischen <[EMAIL PROTECTED]> [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: > >> > >>Well, yeah, but are you _really_ sure that you aren't just > >>running something that should be real-time and have priority > >>over other applications? SCHED_FIFO means you will run until > >>you relinquish the CPU (you can only do this as root). If > >>all your threads are well behaved, would this work? Have > >>you tried it? > > > >No, because it wouldn't work. How do we know when to let go > >of the cpu? In my system, the kernel tells you without polling. > > You don't have to know when to "let go of the cpu" if your > threads are well behaved (meaning they block on some event, > or have periods when they wait). They will let go of the > CPU normally. When they're busy, they will not be switched > out (unless perhaps there is an interrupt thread that needs > to run -- I'm not sure how real-time threads get scheduled > against ithreads). > > If your threads are not well behaved (CPU hogs), then that > isn't going to work because they'll probably bog down the > system. Yes, I know how threading works. Unfortunately, your solution is not workable for us. thank you, -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On 10/2/07, Daniel Eischen <[EMAIL PROTECTED]> wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > * Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote: > >> On Tue, 2 Oct 2007, Alfred Perlstein wrote: > >> > >>> * Daniel Eischen <[EMAIL PROTECTED]> [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: > >> > >> Well, yeah, but are you _really_ sure that you aren't just > >> running something that should be real-time and have priority > >> over other applications? SCHED_FIFO means you will run until > >> you relinquish the CPU (you can only do this as root). If > >> all your threads are well behaved, would this work? Have > >> you tried it? > > > > No, because it wouldn't work. How do we know when to let go > > of the cpu? In my system, the kernel tells you without polling. > > You don't have to know when to "let go of the cpu" if your > threads are well behaved (meaning they block on some event, > or have periods when they wait). They will let go of the > CPU normally. When they're busy, they will not be switched > out (unless perhaps there is an interrupt thread that needs > to run -- I'm not sure how real-time threads get scheduled > against ithreads). > > If your threads are not well behaved (CPU hogs), then that > isn't going to work because they'll probably bog down the > system. > See /sys/priority.h realtime is right below ithreads in terms of priority. One of the big motivations for gang scheduling and part of the reason why SMP guests often perform poorly is that apps / VMs don't scale well if they're descheduled from the cpu while holding a lock. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On 10/2/07, Alfred Perlstein <[EMAIL PROTECTED]> wrote: > * Daniel Eischen <[EMAIL PROTECTED]> [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. :) I assume these processes are running as root? There is nothing to prevent the process from never dropping the lock. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Kip Macy <[EMAIL PROTECTED]> [071002 20:24] wrote: > See /sys/priority.h realtime is right below ithreads in terms of > priority. One of the big motivations for gang scheduling and part of > the reason why SMP guests often perform poorly is that apps / VMs > don't scale well if they're descheduled from the cpu while holding a > lock. Yes, exactly the problem, it sucks when process A on CPU 1 runs out of quantum while holding a lock that a runner on CPU 2 wants. -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Alfred Perlstein <[EMAIL PROTECTED]> writes: > 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. Yeah, great idea, cooperative multitasking is the new black! DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Alfred Perlstein <[EMAIL PROTECTED]> writes: > Do you have: > > a) Evidence or a paper to prove that this is a bad idea? I need evidence or a paper to prove that it is a bad idea to allow a userland process to hold the CPU indefinitely? > b) A helpful suggestion? Why don't you tell us what you're actually trying to do, so we can tell you how to do it. > c) An obvious understanding of the problem? I'll show you mine if you show me yours. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 02:05] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > 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. > > Yeah, great idea, cooperative multitasking is the new black! Do you have: a) Evidence or a paper to prove that this is a bad idea? b) A helpful suggestion? c) An obvious understanding of the problem? If not then perhaps one ought to restrict snarky comments to private mail where they will be at least somewhat appreciated. -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Do you have: > > > > a) Evidence or a paper to prove that this is a bad idea? > > I need evidence or a paper to prove that it is a bad idea to allow a > userland process to hold the CPU indefinitely? > > > b) A helpful suggestion? > > Why don't you tell us what you're actually trying to do, so we can tell > you how to do it. > > > c) An obvious understanding of the problem? > > I'll show you mine if you show me yours. It's not worth my time to engage someone with your mind set, you posses neither the technical nor interpersonal skill to be useful to me. For context see my replies in this thread to Kip Macy which explains how one deals with the false-problems you mention. For evidence of existing, however suboptimal, run-to-completion systems see the RTPRIO scheduling knobs. -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Alfred Perlstein <[EMAIL PROTECTED]> writes: > It's not worth my time to engage someone with your mind set, you > posses neither the technical nor interpersonal skill to be useful > to me. This could be the beginning of a wonderful friendship... > For context see my replies in this thread to Kip Macy which explains > how one deals with the false-problems you mention. I did read them, and I'm not convinced at all. You are asking for a large amount of complexity to be added to the system, but you refuse to tell us what you're actually trying to do. Are you worried that we might actually figure out a way to do it without raping the scheduler? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Quoting Alfred Perlstein, who wrote on Thu, Oct 04, 2007 at 03:19:02AM -0700 .. > * Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > Do you have: > > > > > > a) Evidence or a paper to prove that this is a bad idea? > > > > I need evidence or a paper to prove that it is a bad idea to allow a > > userland process to hold the CPU indefinitely? > > > > > b) A helpful suggestion? > > > > Why don't you tell us what you're actually trying to do, so we can tell > > you how to do it. > > > > > c) An obvious understanding of the problem? > > > > I'll show you mine if you show me yours. > > It's not worth my time to engage someone with your mind set, you > posses neither the technical nor interpersonal skill to be useful > to me. Gentlemen... please? -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Thu, 4 Oct 2007, Alfred Perlstein wrote: * Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: Alfred Perlstein <[EMAIL PROTECTED]> writes: Do you have: a) Evidence or a paper to prove that this is a bad idea? I need evidence or a paper to prove that it is a bad idea to allow a userland process to hold the CPU indefinitely? b) A helpful suggestion? Why don't you tell us what you're actually trying to do, so we can tell you how to do it. c) An obvious understanding of the problem? I'll show you mine if you show me yours. It's not worth my time to engage someone with your mind set, you posses neither the technical nor interpersonal skill to be useful to me. For context see my replies in this thread to Kip Macy which explains how one deals with the false-problems you mention. For evidence of existing, however suboptimal, run-to-completion systems see the RTPRIO scheduling knobs. His point about telling us what you're really doing, so we might off other ways to do it is valid. We don't know why you are using homegrown user-level spinlocks instead of pthread mutexes. Priority ceiling mutexes and running in SCHED_RR or SCHED_FIFO is really what tries to address this problem, at least from the vague desciption you give. If you have tried this and they don't work correctly, then one solution is to fix them ;-) -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Wilko Bulte <[EMAIL PROTECTED]> [071004 04:15] wrote: > Quoting Alfred Perlstein, who wrote on Thu, Oct 04, 2007 at 03:19:02AM -0700 > .. > > * Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: > > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > > Do you have: > > > > > > > > a) Evidence or a paper to prove that this is a bad idea? > > > > > > I need evidence or a paper to prove that it is a bad idea to allow a > > > userland process to hold the CPU indefinitely? > > > > > > > b) A helpful suggestion? > > > > > > Why don't you tell us what you're actually trying to do, so we can tell > > > you how to do it. > > > > > > > c) An obvious understanding of the problem? > > > > > > I'll show you mine if you show me yours. > > > > It's not worth my time to engage someone with your mind set, you > > posses neither the technical nor interpersonal skill to be useful > > to me. > > Gentlemen... please? I think that it would behoove us to explain to developers that perhaps helping the users instead of talking down to them would probably catch more flies. I'm really tired of being told what I need by people that do not understand what environment I'm coming from. By not fielding these annoying responses I come across as clueless or perhaps even satiated by the non-help, conversely by answering I am forced to play this game with people that I'm quite certain will not help me even if they are somehow satisfied by the intellectual or sadistic things they are trying to extract. Even after making it clear with Kip what is needed, I have two more developers toying/trolling/etc with me rather than helping me. Here is how I handle the "holy crap your idea is hair-brained", I simply say, "well if you do that, you'll be worse off because of X, Y or Z and missing out on feature A, B or C, buuut, here's how you might accomplish that" So not only do I come across as smart, but also somewhat helpful. I think we should all know that too much of the former without the latter does not paint us in a good light. thank you, -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [071004 06:05] wrote: > > His point about telling us what you're really doing, so we might > off other ways to do it is valid. > > We don't know why you are using homegrown user-level spinlocks > instead of pthread mutexes. Priority ceiling mutexes and running > in SCHED_RR or SCHED_FIFO is really what tries to address this > problem, at least from the vague desciption you give. If you > have tried this and they don't work correctly, then one solution > is to fix them ;-) First of all we're stuck on 6.x, how is threads on this platform? Second off we are contending against other devices in the system that do not run FreeBSD, How do we address that? -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:28] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > It's not worth my time to engage someone with your mind set, you > > posses neither the technical nor interpersonal skill to be useful > > to me. > > This could be the beginning of a wonderful friendship... > > > For context see my replies in this thread to Kip Macy which explains > > how one deals with the false-problems you mention. > > I did read them, and I'm not convinced at all. You are asking for a > large amount of complexity to be added to the system, but you refuse to > tell us what you're actually trying to do. Are you worried that we > might actually figure out a way to do it without raping the scheduler? As already explained by Kip, the goal is to avoid switching out a lock owner due to quantum exhaustion at an inopportune time. We have needs that may wind up not being applicable to FreeBSD, however if we can accomplish this in a way that is not too awful we would likely be sharing the code, no matter how annoying you make it. :) -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Thu, 4 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [071004 06:05] wrote: His point about telling us what you're really doing, so we might off other ways to do it is valid. We don't know why you are using homegrown user-level spinlocks instead of pthread mutexes. Priority ceiling mutexes and running in SCHED_RR or SCHED_FIFO is really what tries to address this problem, at least from the vague desciption you give. If you have tried this and they don't work correctly, then one solution is to fix them ;-) First of all we're stuck on 6.x, how is threads on this platform? I don't _think_ there is anything prohibitive of MFC'ing any libthr bug fixes into 6.x. I would have thought that you would have tried libthr on 6.x and possibly offered up "libthr performance sucks for me, and here's why" :-) You should probably ask David Xu about priority ceiling mutexes work on 6.x. Second off we are contending against other devices in the system that do not run FreeBSD, How do we address that? If you're running in real-time, then you are suppose to have priority over anything else except for ithreads. How much interrupt load is on your system and is ithread processing really going to impact you? If everything is working correctly and your thread that holds a priority ceiling mutex gets swapped out for an ithread, that thread should run again after the ithread. It shouldn't get swapped out for a different thread that doesn't also have its priority elevated (due to holding a similar mutex). I don't know if anyone other than possibly David Xu have tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes, so they may not work as they're suppose to. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
2007/10/3, Alfred Perlstein <[EMAIL PROTECTED]>: > * Daniel Eischen <[EMAIL PROTECTED]> [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 -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Attilio Rao wrote: 2007/10/3, Alfred Perlstein <[EMAIL PROTECTED]>: * Daniel Eischen <[EMAIL PROTECTED]> [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.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Oct 4, 2007, at 10:43 AM, Daniel Eischen wrote:
On Thu, 4 Oct 2007, Alfred Perlstein wrote:
* Daniel Eischen <[EMAIL PROTECTED]> [071004 06:05] wrote:
His point about telling us what you're really doing, so we might
off other ways to do it is valid.
We don't know why you are using homegrown user-level spinlocks
instead of pthread mutexes. Priority ceiling mutexes and running
in SCHED_RR or SCHED_FIFO is really what tries to address this
problem, at least from the vague desciption you give. If you
have tried this and they don't work correctly, then one solution
is to fix them ;-)
First of all we're stuck on 6.x, how is threads on this platform?
I don't _think_ there is anything prohibitive of MFC'ing
any libthr bug fixes into 6.x. I would have thought that
you would have tried libthr on 6.x and possibly offered up
"libthr performance sucks for me, and here's why" :-)
Alfred: The Hurricane team uses 1x1 threading on PowerPC
without problems.
The patch below fixes a NULL pointer dereference in the
POSIX priority cases:
diff -up /b/marcelm/freebsd/6.x/src/lib/libthr/thread/thr_mutex.c ./
thr_mutex.c
--- /b/marcelm/freebsd/6.x/src/lib/libthr/thread/thr_mutex.cSun
Jan 15 21:36:30 2006
+++ ./thr_mutex.c Sun Sep 9 20:58:20 2007
@@ -629,10 +629,14 @@ mutex_lock_common(struct pthread *curthr
/* Unlock the mutex structure: */
THR_LOCK_RELEASE(curthread, &(*m)-
>m_lock);
- clock_gettime(CLOCK_REALTIME, &ts);
- TIMESPEC_SUB(&ts2, abstime, &ts);
- ret = _thr_umtx_wait(&curthread-
>cycle, cycle,
-&ts2);
+ if (abstime != NULL) {
+ clock_gettime(CLOCK_REALTIME,
&ts);
+ TIMESPEC_SUB(&ts2, abstime,
&ts);
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, &ts2);
+ } else
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, NULL);
if (ret == EINTR)
ret = 0;
@@ -712,10 +716,14 @@ mutex_lock_common(struct pthread *curthr
/* Unlock the mutex structure: */
THR_LOCK_RELEASE(curthread, &(*m)-
>m_lock);
- clock_gettime(CLOCK_REALTIME, &ts);
- TIMESPEC_SUB(&ts2, abstime, &ts);
- ret = _thr_umtx_wait(&curthread-
>cycle, cycle,
- &ts2);
+ if (abstime != NULL) {
+ clock_gettime(CLOCK_REALTIME,
&ts);
+ TIMESPEC_SUB(&ts2, abstime,
&ts);
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, &ts2);
+ } else
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, NULL);
if (ret == EINTR)
ret = 0;
I don't know if anyone other than possibly David Xu have
tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes,
so they may not work as they're suppose to.
We use it successfully with the above patch.
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
