Daniel Lezcano wrote:
Pavel Emelyanov wrote:
Daniel Lezcano wrote:
Cedric Le Goater wrote:
- There are several architectures with their own signal functions for
other OS compatibility that have are using _pid and not _vpid
variants of functions. (irix and solaris)
No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
--- ./net/packet/af_packet.c.packetrefcnt 2007-11-08 13:48:22.0
+0300
+++ ./net/packet/af_packet.c2007-11-08 13:54:29.0 +0300
@@ -135,7 +135,9 @@
pls disregard this, Pavel have sent one similar already
Denis V. Lunev wrote:
No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
--- ./net/packet/af_packet.c.packetrefcnt 2007-11-08 13:48:22.0
+0300
+++
Daniel Lezcano wrote:
* the first one is the locking of the network namespace list by
rtnl_lock, so from the timer callback we can not browse the network
namespace list to check the age of the routes. It is a problem I would
like to talk with Denis if he has time
From my point of view, the
Pavel Emelyanov wrote:
Daniel Lezcano wrote:
Pavel Emelyanov wrote:
Daniel Lezcano wrote:
Cedric Le Goater wrote:
- There are several architectures with their own signal functions for
other OS compatibility that have are using _pid and not _vpid
variants of functions. (irix and solaris)
Pavel Emelyanov wrote:
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
* the first one is the locking of the network namespace list by
rtnl_lock, so from the timer callback we can not browse the network
namespace list
Denis V. Lunev wrote:
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
* the first one is the locking of the network namespace list by
rtnl_lock, so from the timer callback we can not browse the network
namespace list to check
Pavel Emelyanov wrote:
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
* the first one is the locking of the network namespace list by
rtnl_lock, so from the timer callback we can not browse the network
namespace list to check the age of the routes. It is a problem I
Denis V. Lunev wrote:
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
* the first one is the locking of the network namespace list by
rtnl_lock, so from the timer callback we can not browse the network
namespace list to check the age of the routes. It is a problem I
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
Denis V. Lunev wrote:
Daniel Lezcano wrote:
* the first one is the locking of the network namespace list by
rtnl_lock, so from the timer callback we can not browse the network
namespace list to check the age
Pavel Emelyanov wrote:
Both lookup the nf_sockopt_ops object to call the get/set callbacks
from, but they perform it in a completely similar way.
Introduce the helper for finding the ops.
Ported at the top of today's net-2.6 tree to resolve conflict
with the patch from Alexey Dobriyan.
With CONFIG_FAIR_CGROUP_SCHED=y, following commands on 2.6.24-rc1 crash
the system.
$ mount -t cgroup none /cgroups
$ ./ns_exec -cm /bin/ls
ns_exec -cm calls clone() to clone the mount namespace and then
executes the '/bin/ls' program in the cloned child.
Some observations
On Thu, Nov 08, 2007 at 03:48:05PM -0800, [EMAIL PROTECTED] wrote:
With CONFIG_FAIR_CGROUP_SCHED=y, following commands on 2.6.24-rc1 crash
the system.
Thanks for reporting the problem. It was caused because of the fact that
current task isn't kept in its runqueue in case of sched_fair class
Provided that CONFIG_HIGHPTE is not set, unuse_pte_range can reduce latency
in swapoff by scanning the page table preemptibly: so long as unuse_pte is
careful to recheck that entry under pte lock.
(To tell the truth, this patch was not inspired by any cries for lower
latency here: rather, this
Whaaa? This patch precisely reverts the swapoff: scan ptes preemptibly
patch just presented. It's a temporary measure to allow existing memory
controller patches to apply without rejects: in due course they should be
rendered down into one sensible patch, and this reversion disappear.
Why does try_to_free_mem_cgroup_pages try for order 1 pages? It's called
when mem_cgroup_charge_common would go over the limit, and that's adding
an order 0 page. I see no reason: it has to be a typo: fix it.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Insert just after
mem_cgroup_charge_common shows a tendency to OOM without good reason,
when a memhog goes well beyond its rss limit but with plenty of swap
available. Seen on x86 but not on PowerPC; seen when the next patch
omits swapcache from memcgroup, but we presume it can happen without.
If we're charging rss and we're charging cache, it seems obvious that
we should be charging swapcache - as has been done. But in practice
that doesn't work out so well: both swapin readahead and swapoff leave
the majority of pages charged to the wrong cgroup (the cgroup that
happened to read them
This patch reinstates the swapoff: scan ptes preemptibly mod we started
with: in due course it should be rendered down into the earlier patches,
leaving us with a more straightforward mem_cgroup_charge mod to unuse_pte,
allocating with GFP_KERNEL while holding no spinlock and no atomic kmap.
19 matches
Mail list logo
