Re: Deferring work in the page fault handler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 21, 2008 at 6:04 PM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote:
> Hi,
>
> In the kmemcheck code I take a lot of page faults from any kernel
> context (with interrupts enabled or disabled). This means that there
> are a lot of things I can't do. Taking locks is dangerous while
> handling a page fault occurring in interrupt context. In addition to
> this, I must _not_ access any memory allocated by kmalloc(), as this
> may generate a new (recursive) page fault.
>
> Currently, I am deferring work to be done later by using a timer that
> triggers every HZ. This allows me to do what I want in the right
> context, e.g. interrupts enabled and no locks taken.
>
> However, the timer triggers even when I don't need it, and once a
> second is usually too slow when I actually do need it. So I am looking
> for a way to schedule my deferred work as soon as interrupts are
> disabled in the context that caused a page fault.
>
> I was reading Matthew Wilcox's paper on softirqs, tasklets, bottom
> halves, task queues, work queues, and timers. But I am still a little
> unsure of the best way to proceed. My requirement of not accessing
> dynamically allocated memory seem unprecedented in the kernel. E.g.,
> one of my earliest attempts included using a kernel thread and waking
> it up from the page fault handler, but this did not work because
> adding the kthread to a runqueue would access dynamically allocated
> memory.
>
> Does it seem like softirqs or tasklets can do what I want?
>
> Help is much appreciated.
>
> Vegard
>

I have not read the patch yet, but this concept interest me very much:

a.   If u tracked every read before it is written - how do u know if
it is written or not?   Ie, for each write, u have to set a bit to
indicate that the byte of memory is written?   or is it done at the
word/page level?

b.   it is only for kernel memory - right?  process memory may be
swapped out, a huge performance tradeoff to make to do that.

c.   how about DMA memory?   (hardware devices will write to
it....which will not trigger the normal pagetable mechanism, so it is
not possible capture writing to these memory?)

d.   any problem with multi-CPU, PAE scenario?

thank you for the education.

-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux