[lkml]   [2003]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] Kernel thread signal handling.
    On Mon, 2003-10-13 at 04:02 -0700, Andrew Morton wrote:
    > Sigh. Using signals to communicate with kernel threads is evil. It keeps
    > on breaking and each site does it differently and we've had plenty of bugs
    > due to this practice.

    The point in cleaning up allow_signal() et al. is that it gets simple
    and it stops breaking. Not that I recall having signal problems with the
    JFFS2 garbage collection thread other than this one, mind you.

    > Is there no way in which jffs2 can be weaned off this obnoxious habit?

    We have a kernel thread which performs garbage collection on our
    log-structured file system, to make space ahead of time for writes to
    happen. It's purely an optimisation -- we also perform garbage
    collection just-in-time in the context of a process which wants to
    actually _write_, if there's no free space but some could be made.

    This garbage collection involves reading, writing and erasing the flash.
    It takes CPU time and power. Sometimes userspace wants it to stop
    happening in the background; sometimes userspace wants it to resume

    So userspace sends SIGSTOP, SIGCONT and SIGKILL to the garbage
    collection thread and all of them have the expected effect.

    Since we handle these signals anyway, the normal wakeup of the GC thread
    when the amount of free space changes is also done by SIGHUP, which
    userspace can also send to trigger a single pass.

    I don't any the benefit in changing this practice.


    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 13:49    [W:0.021 / U:15.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site