[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <481FEDEF.9030901@linux.vnet.ibm.com>
Date: Tue, 06 May 2008 11:04:39 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: linux-mm@...ck.org, skumar@...ux.vnet.ibm.com,
yamamoto@...inux.co.jp, menage@...gle.com, lizf@...fujitsu.com,
linux-kernel@...r.kernel.org, rientjes@...gle.com,
xemul@...nvz.org, kamezawa.hiroyu@...fujitsu.com
Subject: Re: [-mm][PATCH 3/4] Add rlimit controller accounting and control
Andrew Morton wrote:
> On Sun, 04 May 2008 03:08:14 +0530
> Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
>
>> + if (res_counter_charge(&rcg->as_res, (mm->total_vm << PAGE_SHIFT)))
>
> I worry a bit about all the conversion between page-counts and byte-counts
> in this code.
>
> For example, what happens if a process sits there increasing its rss with
> sbrk(4095) or sbrk(4097) or all sorts of other scenarios? Do we get in a
> situation in which the accounting is systematically wrong?
>
We already do all our accounting in pages for total_vm (field of mm_struct).
task_vsize() for example multiplies PAGE_SIZE with total_vm before returning the
result.
> Worse, do we risk getting into that situation in the future, as unrelated
> changes are made to the surrounding code?
>
I can't see that happening, but I'll look again and request reviewers to help me
identify any such problems that can occur.
> IOW, have we chosen the best, most maintainable representation for these
> things?
>
That's a good question. From the sustenance point of view, resource counters
have worked really well so far. Abstracting accounting and tracking from the
controllers has been a good thing. One of the goals of the rlimit controller is
to keep it open for extension, so that others can add their own control for
other resources like mlock'ed pages.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists