Re: [PATCH 3/5] lib: lockless generic and arch independent page table (gpt) v2.

From: Jerome Glisse
Date: Mon Nov 10 2014 - 17:58:31 EST


On Mon, Nov 10, 2014 at 01:47:01PM -0800, Linus Torvalds wrote:
> On Mon, Nov 10, 2014 at 1:35 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Or do you actually have a setup where actual non-CPU hardware actually
> > walks the page tables you create and call "page tables"?
>
> So just to clarify: I haven't looked at all your follow-up patches at
> all, although I've seen the overviews in earlier versions. When trying
> to read through the latest version, I got stuck on this one, and felt
> it was crazy.
>
> But maybe I'm misreading it and it actually has good reasons for it.
> But just from the details I look at, some of it looks too incestuous
> with the system (the split PTL lock use), other parts look really
> really odd (like the 64-bit shift counts), and some of it looks just
> plain buggy (the bitops for synchronization). And none of it is all
> that easy to actually read.

I hope my other emails explained the motivation for all this. The PTL
because update will happen concurrently as CPU page table update and
as CPU page table update i want the same kind of concurrency btw update
to disjoint address.

For 64bit shift and count i explained it is because some hw will have
a 64bit entry format for the page table no matter what arch they are
on (64bit hw page table on x86 32bit page table).

For bitop they are not use for synchronization but as flag inside a
single CPU thread and never share among different thread. This are
not synchronization point.


Sadly no matter how we wish code that is clear in our mind does not
necessarily end up as clear for other and i know the whole macro
things does not make this any easier. As i said the v1 is a non macro
version but it does pre-compute more things inside init and use more
of this precomputed value as parameter for CPU walk down.

Cheers,
Jérôme

>
> Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/