linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sonny Rao <sonnyrao@us.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
Date: Fri, 7 Nov 2008 17:25:49 -0600	[thread overview]
Message-ID: <20081107232549.GE16240@us.ibm.com> (raw)
In-Reply-To: <18707.53757.132643.518167@cargo.ozlabs.ibm.com>

On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
> Sonny Rao writes:
> 
> > Fix the BSR driver to allow small BSR devices, which are limited to a
> > single 4k space, on a 64k page kernel.  Previously the driver would
> > reject the mmap since the size was smaller than PAGESIZE (or because
> > the size was greater than the size of the device).  Now, we check for
> > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
> > as the remap_pfn functions will do this for us.
> 
> Thanks.
> 
> Do we know that the BSR size will always be 4k if it's not a multiple
> of 64k?  Is it possible that we could get 8k, 16k or 32k or BSRs?
> If it is possible, what does the user need to be able to do?  Do they
> just want to map 4k, or might then want to map the whole thing?

Hi Paul, the BSR comes in 4 different sizes, 8, 16, 64, 128.

The 8 byte BSR registers are always contained to 4k pages and are
always representing a piece of a larger BSR, but can be assigned to
individual LPARs.  

The 16 byte BSR is contained in two 4k pages, and so the code as
patched would not allow both 4k pages to be mapped.  However, I don't
see any reason for the user to need both 4k pages.  

To give some background as to why the BSR exists in multiple pages at
all I'll say that one proposed way to use the BSR is to have each
participating cpu "own" a cache-line sized piece of the BSR mapped
page and write only to that piece.  The reasoning is that using this approach,
software could use either a BSR or regular cachable memory for the
barrier operation, and I would not need to know which it is actually
using.  So in this type of scenario, there should be enough
cache-lines sized pieces mappable. In the case of the 16 byte BSR, one
4k page contains 32 128byte cache-line pieces.  So this is enough to
still use the BSR in this way.

The 64 byte BSR is contained in 16 4k-pages -- so one 64k page works
there, and the 128 byte BSR is contained in 32 4k pages.

The case of the 16 byte BSR is the only one where it matters, I can
change the code to map both 4k pages if the user requests it, but I
don't see any extra utility.  For consistency though, maybe we should
reject a request to map more than 4k but less than 64k on a 64k kernel?

Sonny

  reply	other threads:[~2008-11-07 23:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-07  0:38 [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel Sonny Rao
2008-11-07  5:28 ` Paul Mackerras
2008-11-07 23:25   ` Sonny Rao [this message]
2008-11-17  7:26   ` Sonny Rao
2008-11-19  4:07     ` Paul Mackerras
2008-11-19 17:04       ` Sonny Rao
2008-11-19 22:54         ` Paul Mackerras
2008-11-20 19:20           ` Sonny Rao
2009-06-19  1:13     ` Sonny Rao

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=20081107232549.GE16240@us.ibm.com \
    --to=sonnyrao@us.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.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 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).