Re: [patch -mm 09/18] oom: add forkbomb penalty to badness heuristic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Add a forkbomb penalty for processes that fork an excessively large
> number of children to penalize that group of tasks and not others.  A
> threshold is configurable from userspace to determine how many first-
> generation execve children (those with their own address spaces) a task
> may have before it is considered a forkbomb.  This can be tuned by
> altering the value in /proc/sys/vm/oom_forkbomb_thres, which defaults to
> 1000.
> 
> When a task has more than 1000 first-generation children with different
> address spaces than itself, a penalty of
> 
> 	(average rss of children) * (# of 1st generation execve children)
> 	-----------------------------------------------------------------
> 			oom_forkbomb_thres
> 
> is assessed.  So, for example, using the default oom_forkbomb_thres of
> 1000, the penalty is twice the average rss of all its execve children if
> there are 2000 such tasks.  A task is considered to count toward the
> threshold if its total runtime is less than one second; for 1000 of such
> tasks to exist, the parent process must be forking at an extremely high
> rate either erroneously or maliciously.
> 
> Even though a particular task may be designated a forkbomb and selected as
> the victim, the oom killer will still kill the 1st generation execve child
> with the highest badness() score in its place.  The avoids killing
> important servers or system daemons.  When a web server forks a very large
> number of threads for client connections, for example, it is much better
> to kill one of those threads than to kill the server and make it
> unresponsive.

Reviewers need to trace patch author's intention, this description seems
only focus "how to implement". but reviewers need the explaination of the 
big picture.

The old stragegy is here
  (1) accumulate half of child vsz
  (2) instead, kill the child at first

Your stragegy is here
  (a) usually dont accumulate child mem
  (b) but short lived child is accumulated
  (c) kill the child at first

I think, at least two explaination is necessary.

 - Usually, legitimate process (e.g. web server, rdb) makes a lot of
   1st generation child. but forkbomb usually makes multi level generation
   child. why do you only care 1st generation?
 - In usual case, your don't care the child rsz. but kill the child.
   That seems inconsistency than old. Why do you choose this technique?

Now, I don't have any objection at all because I haven't understand your point.
Ok, the concept of forkbomb detection is good. but need to describe

 - why do you choose this way?
 - how do you confirm your ways works fine?

Any heuristic can't reach perfect in practical. that's ok. but unclear
code intention easily makes code unmaintable. please avoid it.






--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]