From: Jay Lan <jlan@engr.sgi.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Frank van Maarseveen <frankvm@frankvm.com>,
Christoph Lameter <clameter@engr.sgi.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.14-rc2] fix incorrect mm->hiwater_vm and mm->hiwater_rss
Date: Tue, 27 Sep 2005 14:47:34 -0700 [thread overview]
Message-ID: <4339BDF6.3070706@engr.sgi.com> (raw)
In-Reply-To: <4339AED4.8030108@engr.sgi.com>
Jay Lan wrote:
> Hugh Dickins wrote:
>
>> On Wed, 21 Sep 2005, Frank van Maarseveen wrote:
>>
>>> What about calling
>>>
>>> static inline void grow_total_vm(struct mm_struct *mm, unsigned long
>>> increase)
>>> {
>>> mm->total_vm += increase;
>>> if (mm->total_vm > mm->hiwater_vm)
>>> mm->hiwater_vm = mm->total_vm;
>>> }
>>>
>>> whenever total_vm is increased and possibly doing something similar
>>> for rss at
>>> different places? If it is not on the fast path then it's not
>>> necessary to
>>> #ifdef the thing anywhere.
>>
>>
>>
>> I think there's a good argument for separating hiwater_vm and hiwater_rss
>> completely (and you don't seem to be interested in hiwater_rss yourself).
>>
>> hiwater_rss is on some fast paths: well, I don't see them as fast paths
>> myself (the page faults), but they are of exceptional concern to
>> Christoph,
>> and the less we have to mess with struct mm at those points the
>> happier he
>> is. I guess hiwater_rss should remain updated from the timer tick for
>> now.
>>
>> But I think you're right that hiwater_vm is best updated where total_vm
>> is: I'm not sure if it covers all cases completely (I think there's one
>> or two places which don't bother to call __vm_stat_account because they
>> believe it won't change anything), but in principle it would make lots of
>> sense to do it in the __vm_stat_account which typically follows adjusting
>> total_vm, as you did, and if possible nowhere else; rather than adding
>> your inline above.
Just looked at the __vm_stat_account() code. It is enclosed inside
#ifdef CONFIG_PROC_FS.
If that is necessary, i can not put hiwater_vm update code in there. The
system accounting code should not be dependent on a config flag that has
nothing to do with system accounting.
Thanks,
- jay
>
>
> While in the work on separating hiwater_vm from hiwater_rss, i noticed
> that __vm_stat_account() was not called in these functions where
> total_vm was updated:
> mm/mmap.c do_brk
> mm/nommu.c do_mmap_pgoff
> mm/nommu.c do_munmap
> arch/ppc64/kernel/vdso.c arch_setup_additional_pages
> arch/x86_64/ia32/syscall32.c syscall32_setup_pages
>
> Frank tried to touch the latter two in his proposed patch.
> Does it make sense we add __vm_stat_account() calls to the above
> routines?
>
> - jay
>
>
>>
>> Would you be satisfied with that, Christoph?
>>
>> I should warn you that I'll shortly (shortly meaning in days rather
>> than hours) be sending Andrew a patch which will remove the "__" from
>> __vm_stat_account, since the old vm_stat_account is now hardly used.
>> I'm also rearranging the rss,anon_rss accounting. Maybe come back
>> to the hiwaters later on?
>>
>> Hugh
>
>
next prev parent reply other threads:[~2005-09-27 21:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 12:19 [PATCH 2.6.14-rc2] fix incorrect mm->hiwater_vm and mm->hiwater_rss Frank van Maarseveen
2005-09-21 14:38 ` Hugh Dickins
2005-09-21 14:58 ` Frank van Maarseveen
2005-09-21 15:35 ` Hugh Dickins
2005-09-21 18:42 ` Frank van Maarseveen
2005-09-21 18:57 ` Hugh Dickins
2005-09-21 15:26 ` Christoph Lameter
2005-09-21 15:50 ` Frank van Maarseveen
2005-09-21 16:57 ` Jay Lan
2005-09-21 17:05 ` Christoph Lameter
2005-09-21 17:39 ` Jay Lan
2005-09-21 18:06 ` Frank van Maarseveen
2005-09-21 18:38 ` Jay Lan
2005-09-21 17:12 ` Hugh Dickins
2005-09-21 17:31 ` Jay Lan
2005-09-21 17:45 ` Christoph Lameter
2005-09-21 17:46 ` Hugh Dickins
2005-09-21 18:05 ` Jay Lan
2005-09-21 18:26 ` Frank van Maarseveen
2005-09-21 19:19 ` Hugh Dickins
2005-09-21 19:28 ` Frank van Maarseveen
2005-09-21 19:38 ` Jay Lan
2005-09-21 19:47 ` Hugh Dickins
2005-09-21 19:48 ` Frank van Maarseveen
2005-09-21 19:52 ` Hugh Dickins
2005-09-21 19:48 ` Christoph Lameter
2005-09-21 20:06 ` Hugh Dickins
2005-09-21 20:13 ` Christoph Lameter
2005-09-27 20:43 ` Jay Lan
2005-09-27 21:47 ` Jay Lan [this message]
2005-09-27 21:50 ` Christoph Lameter
2005-09-27 22:43 ` Jay Lan
2005-09-28 13:18 ` Hugh Dickins
2005-09-28 17:31 ` Jay Lan
2005-10-03 19:53 ` Hugh Dickins
2005-10-04 8:59 ` Frank van Maarseveen
2005-10-04 21:48 ` Jay Lan
2005-10-07 2:09 ` Jay Lan
2005-10-07 3:03 ` Hugh Dickins
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=4339BDF6.3070706@engr.sgi.com \
--to=jlan@engr.sgi.com \
--cc=clameter@engr.sgi.com \
--cc=frankvm@frankvm.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.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.