>The >short and long of it: the problem can be solved, and it will. Couple >simple things we already do: mlockall() to keep the daemon un-swapped, >and also looking into potential dependency created by syslog (there's >one for 2.4 kernel, not sure if this is an issue for 2.6).
I think it's probably possible and good to do most of this complex stuff in user space, but it looks to me like it's going down exactly the wrong road. Its fundamental to Unix architecture that user programs sit above the kernel and get services from the kernel, and turning that on its head so that the kernel depends on a user space program to do something as fundamental as a pageout can't come to any good. Even if we're able to identify every assumption in Linux design that's being broken and patch it up with something like mlockall, tomorrow someone will change something, using his vast experience with engineering user space programs, and break it again. Maybe a more important point is that to the extent that you make a user space process a proxy of the kernel, you lose all those advantages that are supposed to come with user space engineering: you can now totally hose your system by making a mistake in the code; you have to be intimately familiar with kernel internals to get the code right, etc. mlockall is meant to provide performance characteristics to a user space process. If it can be used to create resource ordering correctness, it's an accident. Syslog is one of those things you're not supposed to have to think about. If every time you issue a message you have to visualize the entire syslog system with all of its options to know if you've broken something, the simplicity of user space is gone. I would think as a basic design principle that if kernel code ever has to wait for a user process to do something, it should do it high in a system call, in user context, interruptibly, etc. I don't know if it's possible to arrange to have the ISCSI initiator waiting there, but I think it's the only way having a user space process can do what it's supposed to do. I'd like to remind everyone that user space processes aside, there's still a basic ISCSI initiator resource inversion that needs to be fixed to avoid deadlock: ISCSI initiator driver sits below the memory pool (I..e a pageout involving ISCSI might be prerequisite to getting memory) Socket layer sits below ISCSI (ISCSI initiator driver relies on socket services) Memory pool sits below socket layer (socket layer allocates memory from the main pool) One might say as long as that's there, close is good enough on the user space initiator component. -- Bryan Henderson San Jose California IBM Almaden Research Center Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
