Fwd: [RFC] Kernel shared variables

[Attilio Rao]

2012/6/2 Konstantin Belousov <kostikbel at gmail.com>:
> On Sat, Jun 02, 2012 at 06:00:06PM +0100, Attilio Rao wrote:
>> Sorry, resending with all the recipients in.
>>
>> Attilio
>>
>>
>> ---------- Forwarded message ----------
>> From: Attilio Rao <attilio at freebsd.org>
>> Date: 2012/6/2
>> Subject: Re: [RFC] Kernel shared variables
>> To: Konstantin Belousov <kostikbel at gmail.com>
>>
>>
>> 2012/6/2 Konstantin Belousov <kostikbel at gmail.com>:
>> > On Sat, Jun 02, 2012 at 02:01:35PM +0100, Attilio Rao wrote:
> [Tried to trim the text]
>
>> >> I think, he just wants to map in userland processes some pages from
>> >> the static image of the kernel (packed together in a specific
>> >> dataset). This imposes some non-trivial problem. The first thing is
>> >> that the static image is not thought to have physical pages tied to
>> >> it. The second is that he needs to make a clean design in order to let
>> >> consumer of this mechanism to correctly locate informations they want
>> >> within the shared page(s) and in the end read the correct values.
>> > Right, exactly, and this is why I object to the "offsets" approach.
>> > It basically moves us to the old times of the "jump tables" shared
>> > libraries, that fortunately was never a case for FreeBSD even when
>> > a.out was used.
>>
>> I'm objecting to this either.
> My english is not good enough to understand this. Do you agree or disagree
> with my statement that 'indexes' make it very hard to maintain ABI ?

I agree with you. The offset approach just doesn't work clean on an
ABI perspective.

>> >>
>> >> I have some reservations on both the implementation and the approach
>> >> for retrieving datas from the page.
>> >> In particular, I don't like that a new vm_object is allocated for this
>> >> page. What I really would like would be:
>> >> 1) very minimal implementation -- you just use
>> >> pmap_enter()/pmap_remove() specifically when needed, separately, in
>> >> fork(), execve(), etc. cases
>> > Oh, this simply cannot work.
>>
>> And why? Assuming you provide a vm_page_t from an UMA zone just like
>> fakepage do. Of course you cannot recycle for this purpose any page
>> caming from vm_page_alloc().
> Due to pv_collect/pmap_pv_reclaim, the pte might be destroyed any time.
>
> Using hacks like mapping the page wired and then needing to hack
> any VM space manipulation (fork/rfork/exec/exit/swapout/I possibly
> missed several cases) just does not pay for it.

Well my take was to map the page wired because of the nature of the
workload too (static image -- present in memory -- wired page).


[ trim ]

>> The gettimeofday() implementation is a different story than what is asked here.
>
> But the goal is to have fast clocks, right ? What else is planned ?
>
> In fact, I think that if the whole goal is only fast clocks, then we
> do not need any additional system mechanisms, since we can easily export
> coefficients for rdtsc formula already. E.g. we can put it into elf auxv,
> which is ugly but bearable.

Not sure if there is anything else besides gettimeofday() that we want
right now, in particular on global basis.
I just mean to say that I don't think Giovanni put a lot of effort in
correctness/robustness of gettimeofday userland implementation, so we
should not judge that part of the patch too tightly.

>> > Interesting question is how much shared the shared page needs be.
>> > Obvious needs are shared between all same-ABI processes, but I can also
>> > easily see a need for the per-process private information be present in
>> > the 'private-shared' page. For silly but typical example, useful for
>> > moronix-style benchmarks, see getpid().
>>
>> Really the performance benefits of having fast getpid() is marginal if
>> compared to heavilly used things like gettimeofday(). I cannot think
>> of a per-process page implementing a fast syscall that can bring many
>> perfomance advantages.
>
> This is completely true, but there may be other process-private data that
> could benefit from the low access cost. I just do not know right now.

I don't know either, thus I don't think there is a big urgence for
per-process shared pages at all.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein