From: Brian King <brking@linux.vnet.ibm.com>
To: Milton Miller <miltonm@bga.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [1/1] powerpc: Update page in counter for CMM
Date: Tue, 21 Oct 2008 15:24:36 -0500 [thread overview]
Message-ID: <48FE3A84.2070207@linux.vnet.ibm.com> (raw)
In-Reply-To: <200810210436.m9L4aepT056796@sullivan.realtime.net>
Milton Miller wrote:
> X-Patchwork-Id: 5144
>> diff -puN arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure arch/powerpc/mm/fault.c
>> --- linux-2.6/arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure 2008-10-20 17:13:25.000000000 -0500
>> +++ linux-2.6-bjking1/arch/powerpc/mm/fault.c 2008-10-20 17:13:25.000000000 -0500
> ..
>> @@ -318,9 +320,11 @@ good_area:
>> goto do_sigbus;
>> BUG();
>> }
>> - if (ret & VM_FAULT_MAJOR)
>> + if (ret & VM_FAULT_MAJOR) {
>> current->maj_flt++;
>> - else
>> + if (firmware_has_feature(FW_FEATURE_CMO))
>> + atomic_inc((atomic_t *)(&(get_lppaca()->page_ins)));
>> + } else
>> current->min_flt++;
>> up_read(&mm->mmap_sem);
>> return 0;
>
> (1) why do we need atomic_inc and the hundreds or thousands of cycles to
> do the atomic inc in a per-cpu area?
We don't. I've now removed it.
> (2) assuming we make this a normal increment, should we keep the
> feature test or just do it unconditionally (ie is the additional load
> and branch worse that just doing the load and store of the counter --
> the address was previously reserved, right? (no question if
> it has to be atomic).
Simplified patch on the way...
> <Ramble things one might consider>
>
> Ben asked if we need to worry about the hypervisor clearing the
> count. If they treat it as a only-incrementing then we don't need
> to worry. And since its only an indicator, then we may not care
> about a big count by them interrupting between the load and store
This is a read only field from the hypervisor's perspective. They
shouldn't be clearing it.
> If we are worried about linux preemption, then we need to disable
> it to avoid crossing cpu variables or getting to this point multiple
> times. (I have not looked at the context to see if we are already
> disabled).
Looks to me like linux preemption is a possibility in this code, so
I've added the code to disable preemption around the increment.
-Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
next prev parent reply other threads:[~2008-10-21 20:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-20 22:19 [PATCH 1/1] powerpc: Update page in counter for CMM Brian King
2008-10-21 4:36 ` [1/1] " Milton Miller
2008-10-21 20:24 ` Brian King [this message]
2008-10-21 20:27 ` [PATCHv2 1/1] " Brian King
2008-10-22 0:11 ` Benjamin Herrenschmidt
2008-10-22 15:53 ` [PATCHv3 " Brian King
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=48FE3A84.2070207@linux.vnet.ibm.com \
--to=brking@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=miltonm@bga.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).