linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).