[lkml]   [2004]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

    [shoot me, I forgot the Cc's the first time]

    > > + /*
    > > + * Tell VM to act less aggressively and fail earlier.
    > > + * This is not necessary but increases throughput.
    > > + * FIXME: Is this really intelligent?
    > > + */
    > > + current->flags &= ~PF_MEMALLOC;
    > This is a bit peculiar. Is it still the case that it increases throughput?

    Were there changes to the VM?

    > How come?

    I'm not exactly sure either. But this is what I suspected:

    The VM wants to write out some pages. dm-crypt wants to allocate buffers
    and starts digging into the reservers because PF_MEMALLOC is set which
    causes some sort of low-memory condition.

    If PF_MEMALLOC is dropped here the VM can just drop some cache pages in
    order to allocate buffers.

    If there wasn't a lot of free (unused) memory the machine often started
    writing out data when I tried to write a lot of data using dd. The
    seeking killed performance, just for the first seconds though.

    It's not really important, I can drop that.

    > Should restore PF_MEMALLOC here.


    > > + set_task_state(current, TASK_INTERRUPTIBLE);
    > > + while (!(bio = kcryptd_get_bios())) {
    > > + schedule();
    > > + if (signal_pending(current))
    > > + return 0;
    > > + }
    > This will turn into a busy-loop, because schedule() sets current->state to
    > TASK_RUNNING. You need to move the set_task_state(current,
    > TASK_INTERRUPTIBLE); inside the loop.

    Right again. I changed that several times. It shouldn't happen that
    schedule returns but there's not data available, but ok. I changed the
    while to an if and call kcryptd_get_bios after schedule().

    > Why is this code mucking with signals?

    For thread termination, that's what kthread does. The other kthread
    users are doing this too. I changed the for(;;) back to a while
    (!signal_pending(current)) since I killed the inner while loop.

    > Perhaps a call to blk_congestion_wait() would be appropriate here.

    Huh? Why that? This is the path for reads.

    > sprintf("%02x")?

    Ok. :)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:00    [W:0.023 / U:7.876 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site