lkml.org 
[lkml]   [1997]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Kernel virtual memory?
On Aug 8,  2:29am, Mark Hemment wrote:
Subject: Re: Kernel virtual memory?
>On Thu, 7 Aug 1997, Victor Yodaiken wrote:
>> Shuffling buffers has bad implications for SMP since it will require
>> synchronizing tlb flushes on all cpus!
>
>By buffers, I assume you mean pages.

I was assuming that there were pages contained in buffers.

> Most of the problems can be overcome by the ordering of operations, and
>a new pte primitive in include/asm/pgtable.h (pte_mkpage() which just
>changes the physical-page bits in a pte, and leaves the attributes bits
>alone). flush_tlb_page() and friends can take care of most problems.


Kernel pages should, in general, stick in place.
It's one thing to move per-process
pages in a process that is only running on one processor. It is something
else to move a kernel global structure, forcing all cpus to invalidate
tlbs at a common sync point. So the problem is not how you change the
physical page bits in the PTE, the problem is the consequence of
changing those bits.

I'm particularly concerned with implications for Real-Time, although there
are obvious performance implications for non-rt as well. One of the
big wins for monolithic kernel design over micro-kernel is that it is
much easier to get a high tlb hit rate in the monolithic kernel.
If kmalloced pages can move, however, each move forces a tlb flush
+ global spinlock.
For RT there are three issues. First, invalidating the tlb will hammer
response time for a rt-task (I'm very curious about cyrix where
you can lock in some cache lines). Second, what happens if a
tlb invalidate irq is asserted during the execution of a rt-task?
The solution I want to implement would be for the invalidate irq
handler to promise to flush and return to the rt-task. Then before
we return to linux-proper, we would actually commit the flush. This makes
it easy to make smp-invalidate "virtually" non-maskable.
All this assumes that pages used by the rt-task will never be moved
by Linux-proper. If this assumption is not correct, then rt becomes
impossible on Linux because a non-rt process on one cpu will
effectively be able to stop a rt-task on a second cpu.
So, issue 3, is that is module code/data or kmalloced pages we use
for communication or other rt space must not be subject to
moves. Static resource allocation is the golden rule of real-time
response.

> A major problem with threading the Memory Management code (not just with
>moving pages), is bits in a pte which can be changed asychronously by the
>h/w. For most archs, these attributes are 'referenced' and 'dirty'. Any
>kernel locking cannot avoid these races [as they are changed without
>entering kernel-space].
> Currently, 'dirty' is not a major problem due to the early marking dirty
>marking. And if we miss a 'referenced' the only effect is poor selection
>of a page for reaping. Under the scheme I'm implementing neither of these
>cases are acceptable.
> The solution I have in mind seems both simple and effective, although I
>must admit to not fully thinking it through at the moment;
> While changing a pte, I remove the 'present' bit and flush the
>change to all engines.

But this is precisely the expensive and problematic synchronization I
want to avoid.



\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.518 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site