Hi Joel, Thanks for your review. > I believe these should be 2 patches. In the first patch you introduce the > new API, in the second one you would simplify the VSOC driver. > > In fact, in one part of the patch you are using wait_event_freezable which > already exists so that's unrelated to the new API you are adding. Agree, I will split the patch for the v2. > > +/* > > + * like wait_event_hrtimeout() -- except it uses TASK_INTERRUPTIBLE to avoid > > + * increasing load and is freezable. > > + */ > > +#define wait_event_freezable_hrtimeout(wq_head, condition, timeout) \ > > You should document the variable names in the header comments. Agree. This comment was copy/pasted from wait_event_freezable_timeout, should I fix it there as well? > Also, this new API appears to conflict with definition of 'freezable' in > wait_event_freezable I think, > > wait_event_freezable - sleep or freeze until condition is true. > > wait_event_freezable_hrtimeout - sleep but make sure freezer is not blocked. > (your API) > > It seems to me these are 2 different definitions of 'freezing' (or I could be > completely confused). But in the first case it calls try_to_freeze after > schedule(). In the second case (your new API), it calls freezable_schedule(). > > So I am wondering why is there this difference in the 'meaning of freezable'. > In the very least, any such subtle differences should be documented in the > header comments IMO. It appears that freezable_schedule() and schedule(); try_to_freeze() are almost identical: static inline void freezable_schedule(void) { freezer_do_not_count(); schedule(); freezer_count(); } and static inline void freezer_do_not_count(void) { current->flags |= PF_FREEZER_SKIP; } static inline void freezer_count(void) { current->flags &= ~PF_FREEZER_SKIP; /* * If freezing is in progress, the following paired with smp_mb() * in freezer_should_skip() ensures that either we see %true * freezing() or freezer_should_skip() sees !PF_FREEZER_SKIP. */ smp_mb(); try_to_freeze(); } as far as I understand this code, freezable_schedule() avoids blocking the freezer during the schedule() call, but in the end try_to_freeze() is still called so the result is the same, right? I wonder why wait_event_freezable is not calling freezable_schedule(). That being said, I am not sure that the try_to_freeze() call does anything in the vsoc case because there is no call to set_freezable() so the thread still has PF_NOFREEZE... regards, Hugo -- Hugo Lefeuvre (hle) | www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C