On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote: > Rik van Riel wrote: > > Andrea Righi wrote: > >> I'm looking for a way to keep track of the processes that fail to > >> allocate new > >> virtual memory. What do you think about the following approach > >> (untested)? > > > > Looks like an easy way for users to spam syslogd over and > > over and over again. > > > > At the very least, shouldn't this be dependant on print_fatal_signals? > > > > Anyway, with print-fatal-signals enabled a user could spam syslogd too, simply > with a (char *)0 = 0 program, but we could always identify the spam attempts > logging the process uid... > > In any case, I agree, it should depend on that patch... > > What about adding a simple msleep_interruptible(SOME_MSECS) at the end of > log_vm_enomem() or, at least, a might_sleep() to limit the potential > spam/second > rate?
An msleep will slow down this process, but do nothing about slowing down the amount of logging. Simply fork a few more processes and all you are doing with msleep is polluting the pid space. What about a throttling similar to what ia64 does for floating point assist faults (handle_fpu_swa()). There is a thread flag to not log the events at all. It is rate throttled globally, but uses per cpu variables for early exits. This algorithm scaled well to a thousand cpus. I think this may be a good fit. Good Luck, Robin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/