David S. Miller <[EMAIL PROTECTED]> wrote: > The idea to mark, for example, IPSEC key management daemon's sockets > as critical is flawed, because the key management daemon could hit a > swap page over the iSCSI device. Don't even start with the idea to > lock the IPSEC key management daemon into ram with mlock().
How are you going to swap in the key manager if you need the key manager for doing this? However, I'd prefer a system where you can't dirty mor than (e.g.) 80 % of RAM unless you need this to maintain vital system activity and not more than 95 % unless it will help to get more clean RAM. (Like the priority inheritance suggestion from this thread.) I suppose this to least significantly reduce thrashing and give a very good chance of recovering from memory pressure. Off cause the implementation won't be easy, especially if userspace applications need to inherit priority from different code paths, but in theory, it can be done. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
