Re: kern/37025 (mount_smbfs write performance is <censored>)

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/37025; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: Ephaeton%gmx.net@localhost
Subject: Re: kern/37025 (mount_smbfs write performance is <censored>)
Date: Tue, 23 Mar 2010 19:52:30 +0000

 On Tue, Mar 23, 2010 at 07:30:08PM +0000, Martin S. Weber wrote:
  >>> Now where to go from here? I still believe there's a problem here, 
  >>> although the situation seriously improved in contrast to the eons
  >>> ago when I first filed this PR.
  >>  
  >>  Kernel profiling or fine-grained timing to figure out where the time
  >>  is going? It is likely to be a pain.
  >  
  >  Hell yeah :) I'll also need a pointer on how to do that correctly please.
 
 I mostly don't know; I avoid that kind of thing as much as possible :-/
 
 There's some way to do kernel profiling (in the strict sense of
 getting output for gmon); another way is to explicitly instrument
 interesting paths with time calls at strategic points. dtrace may be
 able to do this for you nowadays... or at least some of it.
 
  >  I've written in an earlier reply to this PR that the stuck processes
  >  are sitting in smbwrq. I don't think it's network related, because they
  >  will sit there stalled until I do an ls in another shell on the share.
 
 Ah, I didn't see that. This means it's probably not either a protocol
 issue or a vfs-level issue but an ordinary synchronization bug in the
 smbfs code.
 
  >  Then, immediately (!), the writing/reading continues.
  >  Please let me know how I can furtherly try to diagnose a stalled
  >  transfer for locking problems or other vfs problems (pointer to howtos
  >  should do it).
 
 That's not so much a (!) -- what it means is that the wakeup() call or
 equivalent condvar operation that should have been done was not done.
 When something else happens, the stuck guy is then also awakened.
 
 The way to find this one is to examine how the smbwrq object is used
 and look for code paths with missing wakeups or race conditions
 between going to sleep and being awakened. I will take a look at it
 sometime myself (but my queue is extremely long...)
 
 If there are multiple things going by the wchan name "smbwrq", hacking
 the names in your kernel to disambiguate them is a good step too.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost