Jeff Sturm wrote:
> W Bauske wrote:
> > > As a last resort, if one tires of seeing those messages, one could up
> > > the default "timeout" value in the debugging locks code to wait for a
> > > longer time before giving the message... :-\
> > >
> >
> > I don't look at the system console much unless there's trouble
> > or I need to shut things down so I rarely look at these messages.
> > The key is they are not specific to boot time. I take it these
> > messages indicate the hang is around 2 seconds, which makes sense
> > given I send 16MB over 100Mb Enet, which would mean PVM is sustaining
> > around 8MB/sec, actually quite good from my point of view. I'm
> > surprised the other processor would have to wait while another
> > processor was receiving network data. The lock must protect large
> > portions of the kernel code. At some point I'll go back and try
> > the 2.4.test series but not real soon.
>
> This is starting to sound familiar.
>
> I'm not really an expert on Linux SMP, but as I recall the coarse
> locking used in the Linux net code was largely responsible for its poor
> showing on the Mindcraft tests, in which they tested a quad processor
> Intel box. There was some discussion at the time on linux-kernel about
> rewriting the net code for 2.3. I don't know whether that happened. It
> certainly hasn't been backported to 2.2.
>
It happened. Big time. I believe DaveM's statement was that it couldn't
get any more multithreaded than it currently is. (Maybe not DaveM, but the
sentiment is there...). Just search the LKML archives for topics like
"softirq" and "net updates". Neat stuff...
- Pete
-- To unsubscribe: send e-mail to axp-list-request@redhat.com with 'unsubscribe' as the subject. Do not send it to axp-list@redhat.com
This archive was generated by hypermail version 2a22 on Sat Jul 1 05:31:30 2000 PDT
Send any problems or questions about this archive to webmaster@alphalinux.org.