So is there a quick way to identify those mplock dependence areas? Once that is done, how long do you think it would take an experienced C programmer to fix most of the issues? Like I said in my first email, all I need is a rough estimate - 1 month, 2 months, etc. Assume full-time, 40 hour week. Finally, how open is the Dfly team to the idea of hiring programmer(s) on an hourly basis to code things up? Obviously they will NOT have commit access but simply write code and submit to Matt et al for approval. Also, everything they develop will be released under the BSD license. I've already contacted some good C coders in Russia who have experience with low-level system development and they are pretty thrilled with prospect of contributing. Let me know what you think.
On Jan 26, 2008 4:53 AM, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > > Michael Neumann wrote: > > Matthew Dillon wrote: > >> I would like to revisit SMP but it isn't going to happen until HAMMER > >> is well into production. I try to encourage others to take up the SMP > >> work but so far there's only been some minor poking around. > > > > IMHO a first step would be to write down all the things that needs to be > > done to get SMP going. > > SMP works, it just doesn't work with a high parallelism in the kernel. > > It's just a question of removing the implicity dependence on the mplock > for common code paths. So the only thing to be done is a) identify common > code paths b) in those paths: either aquire the mplock or protect the > data in a different way c) in other paths that deal with the same data, > adjust accordingly. Easy huh? :) > > My point is that this stuff is all over the place, starting from syscalls, > going to VFS, VM and drivers. > > cheers > simon > > -- > Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ > Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / > Party Enjoy Relax | http://dragonflybsd.org Against HTML \ > Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ > >