[lkml]   [2002]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: suspend-to-{RAM,disk} for 2.5.17

    > > I need to know more than they are sleeping. I also know they are
    > > sleeping *without holding any semaphores*. I need working system to be
    > > able to save state to disk. That's why I hacked it into signal
    > > handler.
    > Sorry, I should have been more clear. I think the signal handler approach
    > is fine for user processes, I was just wondering why you needed anything
    > like that for kernel threads..
    > When a kernel thread is sleeping, I don't see that it has much state at
    > all: it will be re-started anyway on the next boot, and I don't see it
    > having any "state".

    If that kernel thread is sleeping because it waits for disk, it has
    some state, and I do not want to freeze it just now (because it might
    hold some lock). I only want to freeze them at safe point, and it
    seemed to me that for kernel threads it is easiest to mark safe points
    by hand.

    Does it compile for you for now?
    Casualities in World Trade Center: ~3k dead inside the building,
    cryptography in U.S.A. and free speech in Czech Republic.
    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:22    [W:5.153 / U:5.324 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site