All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@in.ibm.com>
To: Kirill Korotaev <dev@sw.ru>
Cc: Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Christoph Hellwig <hch@infradead.org>,
	Pavel Emelianov <xemul@openvz.org>, Andrey Savochkin <saw@sw.ru>,
	devel@openvz.org, Rik van Riel <riel@redhat.com>,
	Andi Kleen <ak@suse.de>, Oleg Nesterov <oleg@tv-sign.ru>,
	Alexey Dobriyan <adobriyan@mail.ru>,
	Matt Helsley <matthltc@us.ibm.com>,
	CKRM-Tech <ckrm-tech@lists.sourceforge.net>
Subject: Re: [PATCH 6/7] BC: kernel memory (core)
Date: Mon, 04 Sep 2006 21:15:47 +0530	[thread overview]
Message-ID: <44FC4A2B.5050004@in.ibm.com> (raw)
In-Reply-To: <44FC1A58.3090506@sw.ru>

Kirill Korotaev wrote:
> Balbir Singh wrote:
>> Kirill Korotaev wrote:

>>> +#ifdef CONFIG_BEANCOUNTERS
>>> +    union {
>>> +        struct beancounter    *page_bc;
>>> +    } bc;
>>> +#endif
>>> };
>>>
>>> +#define page_bc(page)            ((page)->bc.page_bc)
>>
>>
>> Minor comment - page->(bc).page_bc has too many repititions of page 
>> and bc - see
>> the Practice of Programming by Kernighan and Pike
>>
>> I missed the part of why you wanted to have a union (in struct page 
>> for bc)?
> because this union is used both for kernel memory accounting and user 
> memeory tracking.

Ok.. that's good. I remember seeing a user_bc sometime back in the code.
I had some idea about allowing tasks to migrate across resources (bean
counters), which I think can be easily done for user space pages, if the
user limits are tracked separately.

> 
>>> const char *bc_rnames[] = {
>>> +    "kmemsize",    /* 0 */
>>> };
>>>
>>> static struct hlist_head bc_hash[BC_HASH_SIZE];
>>> @@ -221,6 +222,8 @@ static void init_beancounter_syslimits(s
>>> {     int k;
>>>
>>> +    bc->bc_parms[BC_KMEMSIZE].limit = 32 * 1024 * 1024;
>>> +
>>
>>
>> Can't this be configurable CONFIG_XXX or a #defined constant?
> This is some arbitraty limited container, just to make sure it is not
> created unlimited. User space should initialize limits properly after 
> creation
> anyway. So I don't see reasons to make it configurable, do you?

May be its not very important now but configurable limits will help a confused
user. Even if we decide to use this number for now, a constant like
BC_DEFAULT_MEM_LIMIT is easier to read.

>> I wonder if bc_page_charge() should be called bc_page_charge_failed()?
>> Does it make sense to atleast partially start reclamation here? I know 
>> with
>> bean counters we cannot reclaim from a particular container, but for now
>> we could kick off kswapd() or call shrink_all_memory() inline (Dave's 
>> patches do this to shrink memory from the particular cpuset). Or do 
>> you want to leave this
>> slot open for later?
> yes. my intention is to account correctly all needed information first.
> After we agree on accounting, we can agree on how to do reclamaition.
> 

That sounds like a good plan.

-- 

	Balbir Singh,
	Linux Technology Center,
	IBM Software Labs

  reply	other threads:[~2006-09-04 15:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-29 14:33 [PATCH] BC: resource beancounters (v3) Kirill Korotaev
2006-08-29 14:49 ` [PATCH 1/7] introduce atomic_dec_and_lock_irqsave() Kirill Korotaev
2006-08-30  9:59   ` Roman Zippel
2006-08-30 14:57     ` Oleg Nesterov
2006-08-30 10:51       ` Roman Zippel
2006-08-30 15:51         ` Oleg Nesterov
2006-08-30 11:54           ` Roman Zippel
2006-08-30 16:58         ` Dipankar Sarma
2006-08-30 17:25           ` Roman Zippel
2006-08-31 22:58             ` Paul E. McKenney
2006-08-29 14:51 ` [PATCH 2/7] BC: kconfig Kirill Korotaev
2006-08-30  4:05   ` Randy.Dunlap
2006-08-29 14:53 ` [PATCH 3/7] BC: beancounters core (API) Kirill Korotaev
2006-08-30 18:58   ` [ckrm-tech] " Chandra Seetharaman
2006-08-30 19:47     ` Andrew Morton
2006-08-29 14:54 ` [PATCH 4/7] BC: context inheriting and changing Kirill Korotaev
2006-08-30 19:11   ` [ckrm-tech] " Chandra Seetharaman
2006-08-29 14:55 ` [PATCH 5/7] BC: user interface (syscalls) Kirill Korotaev
2006-08-30 19:15   ` [ckrm-tech] " Chandra Seetharaman
2006-08-29 14:58 ` [PATCH 6/7] BC: kernel memory (core) Kirill Korotaev
2006-08-29 18:41   ` Balbir Singh
2006-09-04 12:21     ` Kirill Korotaev
2006-09-04 15:45       ` Balbir Singh [this message]
2006-08-29 20:29   ` [ckrm-tech] " Dave Hansen
2006-09-04 12:23     ` Kirill Korotaev
2006-09-05 16:21       ` Dave Hansen
2006-08-30 19:25   ` Chandra Seetharaman
2006-08-29 14:58 ` [PATCH 7/7] BC: kernel memory (marks) Kirill Korotaev

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=44FC4A2B.5050004@in.ibm.com \
    --to=balbir@in.ibm.com \
    --cc=adobriyan@mail.ru \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=dev@sw.ru \
    --cc=devel@openvz.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=oleg@tv-sign.ru \
    --cc=riel@redhat.com \
    --cc=saw@sw.ru \
    --cc=xemul@openvz.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.