killing tasks itself.
How different may look idea expressed by the different phrases and cold
heads :)
--
Evgeniy Polyakov
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lis
call) is enough, but its up to the implementation.
--
Evgeniy Polyakov
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
he allocation path before userspace makes some
progress. But do not drop existing oom-killer (i.e. its ability to kill
processes) in favour of this new feature. Let's have both and if
extension failed for some reason, old oom-killer will do the things.
--
Evgeniy Polyakov
notify and
kill processes based on its own hueristics is a good idea, but when it
fails to do its work (or does not exist) system has to have ability to
make a progress and invoke a main oom-killer.
--
Evgeniy Polyakov
___
Containers mailing li
ller.
Application can do whatever it wants of course including killing itself
or the neighbours, but this should not be forced as a usage policy.
--
Evgeniy Polyakov
___
Containers mailing list
contain...@lists.lin
state
contrary to oom-killer.
--
Evgeniy Polyakov
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@
On Fri, Jan 23, 2009 at 01:53:04AM +0300, Evgeniy Polyakov (z...@ioremap.net)
wrote:
> > I'm quite certain you've spent more time writing emails to me than merging
> > the patch and testing its possibilities, given your lack of understanding
> > of its very b
start freezing because oom-killer relied on
> > the userspace.
>
> I'm quite certain you've spent more time writing emails to me than merging
> the patch and testing its possibilities, given your lack of understanding
> of its very basic concepts.
How cute :)
Any other
ory. And could
kill some process to free up the ram.
Userspace notifications are great, no problem, but do not rely on them,
since there is a huge world outside the case it works in, which will be
quite unhappy when systems start freezing because oom-killer rel
ot even
remotely, even theoretically allow a lockup. So userspace notifications
are great as long as this is not the only way to have a progress in the
OOM situation. And the highest priority in this case should be kernel
and its tunables (like proposed cgroup
If by the 'userspace' you do not mean special kernel thread, but in
this case there is no difference compared to existing in-kernel code.
At OOM time there is no userspace. We can not wakeup anyone or send (and
expect it will be received) some notification. The o
ething exceptional so that only they have to
be taken into account when doing system-wide operation like OOM
condition handling.
--
Evgeniy Polyakov
___
Containers mailing list
contain...@lists.linux-foundation.org
https://l
s up to him to decide
and not some inner kernel policy.
--
Evgeniy Polyakov
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
ess from a cgroup with a
> lesser oom.victim number. Oom killing could be disabled by setting
> oom.victim=0.
Looks good, except that in some conditions (everyone has zero for
example) victim=0 does not disalbe oom-killer because of !chosen
part of the condition.
usually prefer to call members the same in container usage, since I
always forget where each one should be placed.
--
Evgeniy Polyakov
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
dev->features |= NETIF_F_LLTX;
> + dev->init = veth_dev_init;
> + dev->destructor = veth_dev_free;
> + netif_carrier_off(dev);
> +}
Don't you want to include NETIF_F_SG, NETIF_F_NO_CSUM, NETIF_F_FRAGLIST,
NETIF_F_HIGH
o, nothing is going to call netlink_dump after the initial call since
> the socket is gone.
Argh, userspace socket's sk_data_rady() if dump returned positive value.
So, callback is not freed to allow to put several pages before
NLMSG_DONE via single
ck is attached, but not freed in the
function, but instead is freed next time dump started.
--
Evgeniy Polyakov
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
socket before the request is processed.
So far it is only netfilter and gennetlink, we would see huge dump
from netlink_sock_destruct.
Anyway, that is possible situation, thanks for clearing this up.
--
Evgeniy Polyakov
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
On Wed, Apr 18, 2007 at 12:32:40PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
> > PROTECTED]) wrote:
> >> Sorry, I forgot to put netdev and David in Cc when I first sen
On Wed, Apr 18, 2007 at 10:26:31AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
> > PROTECTED]) wrote:
> >
> >>Sorry, I forgot to put netdev and David in Cc when I
nters should prevent this, but not
100% sure with RCU dereferencing of the descriptor.
--
Evgeniy Polyakov
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
22 matches
Mail list logo
