From: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
To: Christoph Lameter <clameter-sJ/iWh9BUns@public.gmane.org>
Cc: Linux Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: Re: [PATCH 3/5] Switch caches notification dynamically
Date: Tue, 25 Sep 2007 11:46:44 +0400 [thread overview]
Message-ID: <46F8BCE4.4010302@openvz.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0709241406280.30982-RYO/mD75kfhx2SFC9UQUAuF7EQX82lMiAL8bYrjMMd8@public.gmane.org>
Christoph Lameter wrote:
> On Fri, 21 Sep 2007, Pavel Emelyanov wrote:
>
>> The /sys/slab/<name>/cache_notify attribute controls
>> whether the cache <name> is to be accounted or not.
>>
>> For the reasons described before kmalloc caches cannot
>> be turned on.
>
> It looks like the patch is forbidding to turn the notification off? On is
> okay even if there are already objects present?
Yup. If we "on" the notifications we will just receive new events.
> Full slabs may exist that cannot be accounted for now. I guess that is
> okay because we only want to track new allocations?
If we turn notifications off with full slabs in memory we won't be
able to (in case of kmem accounting) release the page's metadata that
the slub_newpage event attached to them.
We can make this by tracking all the full slabs, and at the moment of
"off" walk them and generate slab_free and slab_release_page events,
but does it worth doing it ever?
Thanks,
Pavel
next prev parent reply other threads:[~2007-09-25 7:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-21 9:14 [PATCH 0/5] Kernel memory accounting container (v4) Pavel Emelyanov
[not found] ` <46F38B67.3020609-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-09-21 9:17 ` [PATCH 1/4] Add notification about some major slab events Pavel Emelyanov
[not found] ` <46F38C1D.2080902-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-09-24 21:05 ` Christoph Lameter
2007-09-21 9:19 ` [PATCH 2/5] Generic notifiers for SLUB events Pavel Emelyanov
2007-09-21 9:22 ` [PATCH 3/5] Switch caches notification dynamically Pavel Emelyanov
[not found] ` <46F38D3B.2050608-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-09-24 21:07 ` Christoph Lameter
[not found] ` <Pine.LNX.4.64.0709241406280.30982-RYO/mD75kfhx2SFC9UQUAuF7EQX82lMiAL8bYrjMMd8@public.gmane.org>
2007-09-25 7:46 ` Pavel Emelyanov [this message]
2007-09-21 9:23 ` [PATCH 4/5] Setup the container Pavel Emelyanov
2007-09-21 9:24 ` [PATCH 5/5] Account for the slub objects Pavel Emelyanov
2007-09-21 12:23 ` [PATCH 0/5] Kernel memory accounting container (v4) Balbir Singh
-- strict thread matches above, loose matches on Subject: below --
2007-09-25 14:16 [PATCH 0/5] Kernel memory accounting container (v5) Pavel Emelyanov
[not found] ` <46F91841.9070708-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-09-25 14:22 ` [PATCH 3/5] Switch caches notification dynamically Pavel Emelyanov
[not found] ` <46F919BB.2000701-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-09-25 21:48 ` Christoph Lameter
[not found] ` <Pine.LNX.4.64.0709251447560.5072-RYO/mD75kfhx2SFC9UQUAuF7EQX82lMiAL8bYrjMMd8@public.gmane.org>
2007-09-26 9:39 ` Pavel Emelyanov
[not found] ` <46FA28C9.9060101-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-09-26 17:30 ` Christoph Lameter
[not found] ` <Pine.LNX.4.64.0709261029300.15435-RYO/mD75kfhx2SFC9UQUAuF7EQX82lMiAL8bYrjMMd8@public.gmane.org>
2007-09-27 8:24 ` Pavel Emelyanov
2007-10-01 13:15 ` Balbir Singh
[not found] ` <4700F2E8.5050904-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2007-10-01 13:19 ` Pavel Emelyanov
2007-10-01 13:21 ` Pavel Emelyanov
[not found] ` <4700F476.4070806-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-10-01 13:38 ` Balbir Singh
[not found] ` <4700F85B.5090902-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2007-10-01 13:45 ` Pavel Emelyanov
[not found] ` <4700FA0A.5040707-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-10-01 14:14 ` Balbir Singh
[not found] ` <470100D0.7030700-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2007-10-01 15:45 ` Pavel Emelyanov
2007-10-01 20:39 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46F8BCE4.4010302@openvz.org \
--to=xemul-gefaqzzx7r8dnm+yrofe0a@public.gmane.org \
--cc=clameter-sJ/iWh9BUns@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.