Date: Fri, 17 Nov 2000 10:24:27 +0800 From: "frank xu" <bsdman@hotmail.com> To: arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <F99h9vXsFFsAitVGeSJ000001f0@hotmail.com>
next in thread | raw e-mail | index | archive | help
I have readed an article about KSE from jasone, it's cool, can complete resolve much headache, but you method has same problems as LinuxThread, jasone already talked about it, in new FreeBSD 5.0, why can't we have a new way to go? ----- Original Message ----- From: Alfred Perlstein <bright@wintelcom.net> To: <arch@FreeBSD.ORG> Sent: Friday, November 17, 2000 6:05 AM Subject: potentially simpler approach than scheduler activations. >This is an idea that I hope doesn't generate any major bikesheds, >I just wanted to toss it out as something that someone might >want to research further and possibly complete it. > >It's an idea to make the uthreads library safe against disk IO >blocking the entire process. > >====== > >We could have a pretty good threading system with some minor >tweaks instead of rewriting the proc/scheduler mechanism. > >Afaik we still have problems with: > >a) sysV IPC >b) disk I/O >c) page not preset faults making the entire thread library block > >Solutions: > >a) implement kevent filters for messsage queues and semphore sets > relatively easy. >b) make uthreads use aio for disk files, relatively easy >c) use a syscall that requests that on a page not present but valid > pagefault we generate a signal such as SIGPNP (?) and have the > kernel async page it in handing the process a kevent with the > void * pointer referencing the page that was faulted in async. > Or, have an aio call that the scheduler will call to have the > page filled in. > >I know it's not exactly what you want, but it seems that it would >be a lot easier to implement and at the same time a lot safer >for the kernel. > >I know that by applying these band-aids we aren't completely >solving every problem and as new interfaces pop-up we might >have to apply more band-aids to libc_r, but I think this >might get us past the point of system that breaks down on >disk IO. > >We could then later use rfork threads and a "big giant" over >the uthread schedule to take advantage of multiple processors. > >-- >-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] >"I have the heart of a child; I keep it in a jar on my desk." > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-arch" in the body of the message _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F99h9vXsFFsAitVGeSJ000001f0>