Date: Sun, 8 Mar 1998 01:52:14 -0500 (EST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: nate@mt.sri.com (Nate Williams) Cc: peter@netplex.com.au, nate@mt.sri.com, jb@cimlogic.com.au, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c Message-ID: <199803080652.BAA02132@dyson.iquest.net> In-Reply-To: <199803080603.XAA06928@mt.sri.com> from Nate Williams at "Mar 7, 98 11:03:44 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams said: > > > That's what these changes are about. In spite of the fact that they > > are seperate processes, having the shared address space means we can > > (greatly) streamline context switching between them. > > So, they are more like slightly-lighter weight prorcesses? > They are significantly lighter weight than regular processes. > > We can do that with processes now. As I stated originally, what > advantages do these 'heavy-threads' have over standard processes. So > far the answer is context switches are faster due to shared address > space. Other than that it appears that they are still pretty 'heavy'. > Address space is a big part of a processes overhead. > > I understand. I want the brass ring now, not later. :) :) :) > > I as well as many others couldwrite applications *right now* that could > take advantage of truly lightweight kernel threads for socket > communication. It would be nice to have hundreds if not thousands of > them running around that take up *significantly* less resources than > associated processes. (resources include context switches, but also > include things like memory usage, etc....) > What we are working on is infintely better than a broken (shared mmap) userland implementation, but is also not a brass ring implementation. I can't spend any more time discussing this, but think of this... So we don't share struct proc? How big is it compared to the multiple page table pages, and the page directory page???? Think about it... We are fully leveraging the VM code towards the threads already. The biggest thing wrong with the process model as of now, is the kernel stack thing. We are kind of stuck with the kernel stacks, and if we could get rid of them, that would save at least two more pages per thread. That would mean that we would mostly have struct proc and struct user left. We should rework the scheduler, and if you want, you might want to look at it. I know how to do it, but don't have the bandwidth, and things like this discussion absorb lots of bandwidth, and don't usually inspire progress, but only more demands. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803080652.BAA02132>