wowi understand betterbut still not enough to answer some questions.
On Fri, May 23, 2008 at 1:59 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> On Thu, May 22, 2008 at 7:25 PM, Peter Teoh <[EMAIL PROTECTED]> wrote:
>> Thanks for the reply. I would appreciate if someone can help to
>
On Thu, May 22, 2008 at 7:25 PM, Peter Teoh <[EMAIL PROTECTED]> wrote:
> Thanks for the reply. I would appreciate if someone can help to
> clear just a few more doubts
>
Hi, no problem :-)
> On Thu, May 22, 2008 at 7:31 PM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
>> On 5/22/08, Peter Teoh
Thanks for the reply. I would appreciate if someone can help to
clear just a few more doubts
On Thu, May 22, 2008 at 7:31 PM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> On 5/22/08, Peter Teoh <[EMAIL PROTECTED]> wrote:
>> On Wed, May 21, 2008 at 6:04 PM, Vegard Nossum <[EMAIL PROTECTED]> wro
On 5/22/08, Peter Teoh <[EMAIL PROTECTED]> wrote:
> On Wed, May 21, 2008 at 6:04 PM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> > 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 c
On 5/22/08, Mulyadi Santosa <[EMAIL PROTECTED]> wrote:
> Hi man
>
> First, kudos for your work on kmemchecki haven't tried it by
> myself but I think it's a cool piece of codes.
>
>
> On Wed, May 21, 2008 at 5:04 PM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> >
> > I was reading Matth
On Wed, May 21, 2008 at 6:04 PM, Vegard Nossum <[EMAIL PROTECTED]> 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
On Wed, May 21, 2008 at 6:04 PM, Vegard Nossum <[EMAIL PROTECTED]> 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
Hi man
First, kudos for your work on kmemchecki haven't tried it by
myself but I think it's a cool piece of codes.
On Wed, May 21, 2008 at 5:04 PM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
>
> I was reading Matthew Wilcox's paper on softirqs, tasklets, bottom
> halves, task queues, work
On Wed, May 21, 2008 at 2:13 PM, Rene Herman <[EMAIL PROTECTED]> wrote:
> On 21-05-08 14:08, Rene Herman wrote:
>
>> On 21-05-08 12:04, Vegard Nossum wrote:
>>
>>> In addition to this, I must _not_ access any memory allocated by
>>> kmalloc(), as this may generate a new (recursive) page fault.
>>
>
On 21-05-08 14:08, Rene Herman wrote:
On 21-05-08 12:04, Vegard Nossum wrote:
In addition to this, I must _not_ access any memory allocated by
kmalloc(), as this may generate a new (recursive) page fault.
Do feel free to educate me; I completely don't understand the question.
kmalloc() aloc
On 21-05-08 12:04, Vegard Nossum wrote:
In addition to this, I must _not_ access any memory allocated by
kmalloc(), as this may generate a new (recursive) page fault.
Do feel free to educate me; I completely don't understand the question.
kmalloc() alocated memory is non-swappable. How are yo
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
12 matches
Mail list logo
