![]() | |||||||||||||
Messages in this thread |
[ Trimmed Cc: list ] On 6/30/07, Steve French <smfrench@gmail.com> wrote: > The reason that cifs switched from wait_for_completion to the kthread > call to cifs_demultiplex_thread in the first place is because without > use of kthread it won't work with a linux-vserver. See the thread: > > http://marc.info/?l=linux-cifs-client&m=117552761703381&w=2 > > If we take out the kthread call, we break those guys. > > I agree that using sk_callbacks is worth looking into - I only found > ocfs2 and SunRPC (NFS) though that used it. Is there a better > example though? The NFS socket handling code is huge > (net/sunrpc/xprtsck.c) - something seems wrong when replacing a few > lines of code with a new 1675 line file. There must be a better > example of doing what you suggest... You're correct. "Right" / "elegant" solutions are rarely (if ever?) complex and involved. Simplicity _is_ good. I see no point in converting 5 good lines of maintainable, readable, solid code with 1000 lines of kludge :-) just to work-around this kthreads limitation. But then, of course, the call is yours. > I am tempted to drop the socket timeout (which cifs sets to 7 seconds) > to a smaller number and not use signals at all rather than add that > much complexity Timeout too low => CPU wastage => power wastage. [ Think laptop batteries, with say 5 cifsd kthreads waking up once every second ... ] Timeout too high => umount(2) hangs, annoys user, user takes drastic actions ... so think of some good "magic number" :-) I don't quite think of all these suggestions as solutions at all -- they are workarounds at best, IMHO (for kthread's limitation in dealing with kernel threads that want to block -- I still don't see any fundamental reasoning / logic behind why kthreads should be banned from doing blocking recv's -- if there is, please let me know too). Don't have much else to say than what I already have on the two threads discussing this. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-06-30 14:41 [from the cache] ©2003-2008 | |||||||||||||