Date: Thu, 26 Jun 1997 00:24:21 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: fredriks@Mcs.Net (Lars Fredriksen) Cc: smp@FreeBSD.ORG Subject: Re: Silo overflows with SMP kernel Message-ID: <199706260524.AAA00225@dyson.iquest.net> In-Reply-To: <199706260419.XAA17826@Mercury.mcs.net> from Lars Fredriksen at "Jun 25, 97 11:19:58 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi, > Just a quick comment that I have noticed. This might have > something to do with the granularity of locking that we are currently > running with(ie giant lock), but I have seen a fair amount of silo > overflows while running the SMP kernel. I have a 64Kbs ppp link that > from time to time have a medium load on it.(ie big ftp transfers) > > Is this to be expected until the locking gets more granular or is this > related to something else? > I have been seeing that also... I have a modified SIO driver that fully uses the new 32 byte fifo chips with automatic hardware RTS/CTS flow control. Haven't committed it yet, because it covers up the problem. The good news is that it is likely due to the "big lock" SMP kernel model. If you want a copy of the modified SIO driver, let me know. I am not comfortable enough with it yet to commit it though. Right now, I am working on finer grained VM locking which should be a first step on the VFS/VM high level side to make things better. (I am not one of the "main" SMP people, but am doing what I can do to support them.) By the weekend, my copy of the VM code should be SMP safe, all the way down to the VM object/page level. There are still many many issues to make it "correct", but it is getting closer. Essentially, I should be able to handle a page fault (with no disk I/O) without doing the "big lock" thing. In fact, the VM code should be able to handle simultaneous user page faults on different processors, and manage the locking when data structures are in common. This stuff is less trivial than I had thought... (Translation: it is DA*N difficult.) I am working from 12:00 Noon to 3AM trying to understand and work all of the issues. It is not likely that the stuff that I'll have this weekend will be the final version, but it will be a first step on making the higher VM code real-SMP capable. (Note that I am building on the hard SMP work that has been done by the SMP guys...) John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706260524.AAA00225>