W Bauske wrote:
<snip>
>
> > Which release was this? I'm trying to collect a hit list of locks to go take a
> > look at, and from first glance, it appears this is another lock_kernel() call.
> > Interesting thing is, it's being held in what appears to be llseek(), and tried for
> > in something I can't find (socket.c:43 is still in the comments, at least in 2.2 as
> > is select.c:43...). Seeing as this file:line# pair is generated from the gcc
> > __FILE__ and __LINE__ macros, I'm not sure what's wrong there - Jay?
> >
>
> This is kernel 2.2.15pre17 with a couple minor patches, nfsv3, and
> ide DMA patches. llseek makes no sense. pvmd shouldn't write to disk.
> It is more likely socket calls only, both local and remote. PVM uses
> a UNIX type socket to talk to local processes I believe and an INET
> socket to talk to the world.
>
Hrm....interesting thing is, the only things in read_write.c are (l)lseek, and various
read()s and write()s. Any chance you could match the addresses given in either the
System.map or a disassembly dump (or with gdb)?
>
> If Greg can reproduce similar messages, then I'll let him work with you
> all to sort it out. My point in posting was just to confirm this was
> not a boot time only problem.
>
Interesting thing tho' is that this is coming from different areas than Greg's are.
Greg's messages come from insmod and identd colliding in schedule. Yours are quite
different. Same lock probably, but different nonetheless...
>
> > BTW, it appears that this is happening when the pvmd3 process is reading
> > (apparently large amounts of) data from a socket and writing it to the file, or
> > perhaps the inverse. This could _perhaps_ be improved by writing the data out
> > faster, rather than batching it up in cache. It's only a guess, but it might help
> > if your disk is fast enough. *shrug*
> >
> > - Pete (still muttering about the !@#$*$@#^ kernel lock...)
>
> Large is relative. I'm sending around 16MB of data every 10-50
> secs. Total input dataset is around 300-400GB for this run. The
> systems each use quite fast disk. hdparm shows them at 15+MB/sec.
> There is practically no disk I/O in this code on worker nodes except
> for the end when they save their results.
>
Hmmm....Greg's suggestion to strace it and attempt to correlate the syscall traces would
be really good here. MHO.
- 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.