On Wed, 2008-09-03 at 10:10 -0500, Becky Bruce wrote:
> Actually, PTE_SIZE is already defined in hash_low_32.S, and it's the
> size of the HPTE. I'll rename that to HPTE_SIZE and use PTE_SIZE for
> the linux PTE.
Good idea. Thanks.
Cheers,
Ben.
On Sep 2, 2008, at 4:21 PM, Benjamin Herrenschmidt wrote:
The reason I did that was to distinguish between the size of a
software PTE entry, and the actual size of the hardware entry. In
the
case of 36b physical, the hardware PTE size is the same as it always
is; but we've grown the Linux
> The reason I did that was to distinguish between the size of a
> software PTE entry, and the actual size of the hardware entry. In the
> case of 36b physical, the hardware PTE size is the same as it always
> is; but we've grown the Linux PTE. We can call it something else, or
> I can c
On Sep 1, 2008, at 12:19 AM, Benjamin Herrenschmidt wrote:
Thanks for taking the time to dig through this :)
+#ifdef CONFIG_PTE_64BIT
+#define PTE_FLAGS_OFFSET 4 /* offset of PTE flags, in bytes */
+#define LNX_PTE_SIZE 8 /* size of a linux PTE, in bytes */
+#else
> Could the stw to the same reservation granule as the stwcx cancel the
> reservation on some implementations?
It might I suppose ... In any case, see my replies to Becky.
> Plus, if you're assuming that the
> entry is currently invalid and all callers have the page table lock, do
> we need
> +#ifdef CONFIG_PTE_64BIT
> +#define PTE_FLAGS_OFFSET 4 /* offset of PTE flags, in bytes */
> +#define LNX_PTE_SIZE 8 /* size of a linux PTE, in bytes */
> +#else
> +#define PTE_FLAGS_OFFSET 0
> +#define LNX_PTE_SIZE 4
> +#endif
s/LNX_PTE_SIZE/PTE_BYTES or PTE
On Sat, 2008-08-30 at 11:24 -0500, Scott Wood wrote:
> On Fri, Aug 29, 2008 at 08:42:01AM +1000, Benjamin Herrenschmidt wrote:
> > For the non-SMP case, I think it should be possible to optimize it. The
> > only thing that can happen at interrupt time is hashing of kernel or
> > vmalloc/ioremap pag
On Fri, Aug 29, 2008 at 08:42:01AM +1000, Benjamin Herrenschmidt wrote:
> For the non-SMP case, I think it should be possible to optimize it. The
> only thing that can happen at interrupt time is hashing of kernel or
> vmalloc/ioremap pages, which shouldn't compete with set_pte on those
> pages, so
> I understand what you're saying, I've been here before :) However, I
> was never able to convince myself that it's safe without the lwarx/
> stwcx. There's hashing code that wanks around with the HASHPTE bit
> doing a RMW without holding any lock (other than lwarx/stwcx-ing the
> PTE it
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did in fact need the lwarx/stwcx. IIRC, it
has to do with other non-set_pte_at writers not necessarily holding
the page table lock. FYI
Great, so *you* got my email, and I did not. I love our mailserver!
On Aug 28, 2008, at 3:28 PM, Scott Wood wrote:
Becky Bruce wrote:
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did
Becky Bruce wrote:
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did in fact need the lwarx/stwcx. IIRC, it
has to do with other non-set_pte_at writers not necessarily
holding the page t
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point and
concluded that I did in fact need the lwarx/stwcx. IIRC, it has to do
with other non-set_pte_at writers not necessarily holding the page table
lock. FYI, the existing 32-bit PTE code is doing atomic updates
On Aug 27, 2008, at 6:43 PM, Scott Wood wrote:
Becky Bruce wrote:
#if _PAGE_HASHPTE != 0
+#ifndef CONFIG_PTE_64BIT
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
#else
+ /*
+* We have to do the write of the 64b pte as 2 stores. This
+* code assu
Becky Bruce wrote:
#if _PAGE_HASHPTE != 0
+#ifndef CONFIG_PTE_64BIT
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
#else
+ /*
+* We have to do the write of the 64b pte as 2 stores. This
+* code assumes that the entry we're storing to is currently
15 matches
Mail list logo
