public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Process hangs copying large file to cifs
@ 2004-06-28 21:58 Steve French
  2004-06-29 11:12 ` Nuno Ferreira
  0 siblings, 1 reply; 9+ messages in thread
From: Steve French @ 2004-06-28 21:58 UTC (permalink / raw)
  To: nuno.ferreira; +Cc: linux-cifs-client, linux-kernel

>  > This is copying a 197Mb from an my laptop's IDE hardisk to a cifs 
> mounted share that's on a Win2000 Server

Linus had suggested hashing cifs inodes, which makes sense as related to
the problem that you reported.  I have coded that and it tested out ok
today. If you have a chance could you try the patch at:

http://cifs.bkbits.net:8080/linux-2.5cifs/gnupatch@40e0925dAlasT6JDoPqQE2q3e-zYiw



^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Process hangs copying large file to cifs
@ 2004-06-24  3:16 Steve French
  2004-06-24 10:48 ` Nuno Ferreira
  0 siblings, 1 reply; 9+ messages in thread
From: Steve French @ 2004-06-24  3:16 UTC (permalink / raw)
  To: linux-cifs-client

 > This is copying a 197Mb from an my laptop's IDE hardisk to a cifs 
mounted share that's on a Win2000 Server

This seems strange - looks like cifs simply called generic_write which 
goes to the page manager which in this case had to
rebalance/free up some pages which hung in local filesys routine outside 
of my code which I do not recognize.

[<c028dae0>] schedule_timeout+0x60/0xc0
[<c0131541>] __alloc_pages+0x2c1/0x300
[<c011eb00>] process_timeout+0x0/0x10
[<c028da3e>] io_schedule_timeout+0xe/0x50
[<c01ebe02>] blk_congestion_wait+0x72/0x90
[<c0116470>] autoremove_wake_function+0x0/0x50
[<c0116470>] autoremove_wake_function+0x0/0x50
[<c0132212>] get_dirty_limits+0x12/0xd0
[<c013238d>] balance_dirty_pages+0xbd/0x110
[<c012f5ad>] generic_file_aio_write_nolock+0x3ed/0x980
[<c012e2d0>] file_read_actor+0xc0/0xd0
[<c012e477>] __generic_file_aio_read+0x197/0x1d0
[<c012e210>] file_read_actor+0x0/0xd0
[<c012fb9f>] generic_file_write_nolock+0x5f/0x80
[<c014623f>] do_sync_read+0x6f/0xb0
[<c01060a3>] do_IRQ+0x113/0x150
[<c012fc8e>] generic_file_write+0x3e/0x60
[<de9c05bc>] cifs_write_wrapper+0x4c/0xb0 [cifs]

As you mentioned the vi thread is another one of the threads blocked in 
the local call "blk_congestion_wait" which may be useful to understand.

I don't see any interesting threads in cifs at first glance, although 
the call stack for the cifsoplock thread is a little odd looking (perhaps
some junk being misinterpreted on the call stack).

Could you take a look at the /proc/fs/cifs/DebugData,  which (at least 
on current 2.6.7) displays some often useful debug data
including the lists of "MIDs" (multiplex ids - pending network 
operations on the wire) if any and also /proc/fs/cifs/Stats and 
SimultaneousOps
which display counts of number of operations pending in the vfs which 
looks like only one - in this case - which is blocked outside the cifs code.

My guess is that there actually aren't any interesting threads in cifs 
at the moment, and that we need to understand the
blk_congestion_wait calls are trying to do


^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-08-13 16:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-28 21:58 Process hangs copying large file to cifs Steve French
2004-06-29 11:12 ` Nuno Ferreira
2004-08-12 16:31   ` Nuno Ferreira
2004-08-12 16:31   ` Nuno Ferreira
2004-08-13  6:34     ` Steve French (IBM LTC)
2004-08-12 20:06       ` Nuno Ferreira
2004-08-13 16:21         ` Nuno Ferreira
  -- strict thread matches above, loose matches on Subject: below --
2004-06-24  3:16 Steve French
2004-06-24 10:48 ` Nuno Ferreira

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox