Re: Merging the Suspend2 freezer implementation.
Hi. On Wed, 2005-02-09 at 09:32, Pavel Machek wrote: > Hi! > > > > > The main change involves the introduction of a new SYNCTHREAD flag. We > > > > use this to avoid deadlocking over processes that are running sys_sync > > > > and siblings. Processes that enter those routines get the flag added, > > > > and it's removed when they exit the sync routine. We then freeze in four > > > > stages: > > > > > > Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? > > > > It's necessary for reliable freezing under I/O load. Signalling the > > non-sync threads first removes the race involved in some threads > > submitting I/O while others are trying to sync. Try doing a dd and a > > sync at the same time. The sync can take ages to return, worst case, > > sometimes not until the dd is completed. (Actually, try doing anything > > while a dd is running :>) > > Okay, just attach this explanation when you are merging it otherwise > I'll surely ask again... Okay. > > > > Finally I'd like to merge the support for freezer flags on workqueues. > > > > No comment here? :> > > :-). I forgot why it was neccessary, but I was too shy to ask > ;-). Just attach nice explanation when you attempt to merge it. Okay. Thanks! Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging the Suspend2 freezer implementation.
Hi! > > > The main change involves the introduction of a new SYNCTHREAD flag. We > > > use this to avoid deadlocking over processes that are running sys_sync > > > and siblings. Processes that enter those routines get the flag added, > > > and it's removed when they exit the sync routine. We then freeze in four > > > stages: > > > > Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? > > It's necessary for reliable freezing under I/O load. Signalling the > non-sync threads first removes the race involved in some threads > submitting I/O while others are trying to sync. Try doing a dd and a > sync at the same time. The sync can take ages to return, worst case, > sometimes not until the dd is completed. (Actually, try doing anything > while a dd is running :>) Okay, just attach this explanation when you are merging it otherwise I'll surely ask again... > > > Finally I'd like to merge the support for freezer flags on workqueues. > > No comment here? :> :-). I forgot why it was neccessary, but I was too shy to ask ;-). Just attach nice explanation when you attempt to merge it. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging the Suspend2 freezer implementation.
Hi. On Wed, 2005-02-09 at 03:36, Pavel Machek wrote: > Hi! > > > I'm keen to see if we can merge Suspend2's freezer implementation after > > 2.6.11. Does that conflict with any of your intended changes? If it > > doesn't, I'll submit a patch for review/merge as quickly as I can. > > Freezer is very independend, and no, I do not plan any changes in that area. Ok. > > The main change involves the introduction of a new SYNCTHREAD flag. We > > use this to avoid deadlocking over processes that are running sys_sync > > and siblings. Processes that enter those routines get the flag added, > > and it's removed when they exit the sync routine. We then freeze in four > > stages: > > Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? It's necessary for reliable freezing under I/O load. Signalling the non-sync threads first removes the race involved in some threads submitting I/O while others are trying to sync. Try doing a dd and a sync at the same time. The sync can take ages to return, worst case, sometimes not until the dd is completed. (Actually, try doing anything while a dd is running :>) > > 1) Freeze user space threads without SYNCTHREAD set; > > 2) Freeze user space threads with SYNCTHREAD set; > > 3) Run our own sys_sync in case no one else was syncing > > 4) Freeze kernel space threads without NOFREEZE set. > > > > I'd also like to look at your SMP support and see if we can improve > > compatibility there at the same time. > > Why not... But parts of smp support really need to be in assembly, and > they are not, neither in swsusp nor in suspend2... I don't think there's any issue here - or at least not a significant one. I've had SMP support for just over a year, and I don't believe there are any outstanding SMP specific issues in the freezer code (or anywhere else in suspend2). All the resuming failures people get with Suspend2 are traceable to device drivers (usb, dri/drm, cpufreq, 8139too, e1000 cards...) > > Finally I'd like to merge the support for freezer flags on workqueues. No comment here? :> Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging the Suspend2 freezer implementation.
Hi! > I'm keen to see if we can merge Suspend2's freezer implementation after > 2.6.11. Does that conflict with any of your intended changes? If it > doesn't, I'll submit a patch for review/merge as quickly as I can. Freezer is very independend, and no, I do not plan any changes in that area. > The main change involves the introduction of a new SYNCTHREAD flag. We > use this to avoid deadlocking over processes that are running sys_sync > and siblings. Processes that enter those routines get the flag added, > and it's removed when they exit the sync routine. We then freeze in four > stages: Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? > 1) Freeze user space threads without SYNCTHREAD set; > 2) Freeze user space threads with SYNCTHREAD set; > 3) Run our own sys_sync in case no one else was syncing > 4) Freeze kernel space threads without NOFREEZE set. > > I'd also like to look at your SMP support and see if we can improve > compatibility there at the same time. Why not... But parts of smp support really need to be in assembly, and they are not, neither in swsusp nor in suspend2... > Finally I'd like to merge the support for freezer flags on workqueues. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging the Suspend2 freezer implementation.
Hi! I'm keen to see if we can merge Suspend2's freezer implementation after 2.6.11. Does that conflict with any of your intended changes? If it doesn't, I'll submit a patch for review/merge as quickly as I can. Freezer is very independend, and no, I do not plan any changes in that area. The main change involves the introduction of a new SYNCTHREAD flag. We use this to avoid deadlocking over processes that are running sys_sync and siblings. Processes that enter those routines get the flag added, and it's removed when they exit the sync routine. We then freeze in four stages: Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? 1) Freeze user space threads without SYNCTHREAD set; 2) Freeze user space threads with SYNCTHREAD set; 3) Run our own sys_sync in case no one else was syncing 4) Freeze kernel space threads without NOFREEZE set. I'd also like to look at your SMP support and see if we can improve compatibility there at the same time. Why not... But parts of smp support really need to be in assembly, and they are not, neither in swsusp nor in suspend2... Finally I'd like to merge the support for freezer flags on workqueues. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging the Suspend2 freezer implementation.
Hi. On Wed, 2005-02-09 at 03:36, Pavel Machek wrote: Hi! I'm keen to see if we can merge Suspend2's freezer implementation after 2.6.11. Does that conflict with any of your intended changes? If it doesn't, I'll submit a patch for review/merge as quickly as I can. Freezer is very independend, and no, I do not plan any changes in that area. Ok. The main change involves the introduction of a new SYNCTHREAD flag. We use this to avoid deadlocking over processes that are running sys_sync and siblings. Processes that enter those routines get the flag added, and it's removed when they exit the sync routine. We then freeze in four stages: Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? It's necessary for reliable freezing under I/O load. Signalling the non-sync threads first removes the race involved in some threads submitting I/O while others are trying to sync. Try doing a dd and a sync at the same time. The sync can take ages to return, worst case, sometimes not until the dd is completed. (Actually, try doing anything while a dd is running :) 1) Freeze user space threads without SYNCTHREAD set; 2) Freeze user space threads with SYNCTHREAD set; 3) Run our own sys_sync in case no one else was syncing 4) Freeze kernel space threads without NOFREEZE set. I'd also like to look at your SMP support and see if we can improve compatibility there at the same time. Why not... But parts of smp support really need to be in assembly, and they are not, neither in swsusp nor in suspend2... I don't think there's any issue here - or at least not a significant one. I've had SMP support for just over a year, and I don't believe there are any outstanding SMP specific issues in the freezer code (or anywhere else in suspend2). All the resuming failures people get with Suspend2 are traceable to device drivers (usb, dri/drm, cpufreq, 8139too, e1000 cards...) Finally I'd like to merge the support for freezer flags on workqueues. No comment here? : Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging the Suspend2 freezer implementation.
Hi! The main change involves the introduction of a new SYNCTHREAD flag. We use this to avoid deadlocking over processes that are running sys_sync and siblings. Processes that enter those routines get the flag added, and it's removed when they exit the sync routine. We then freeze in four stages: Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? It's necessary for reliable freezing under I/O load. Signalling the non-sync threads first removes the race involved in some threads submitting I/O while others are trying to sync. Try doing a dd and a sync at the same time. The sync can take ages to return, worst case, sometimes not until the dd is completed. (Actually, try doing anything while a dd is running :) Okay, just attach this explanation when you are merging it otherwise I'll surely ask again... Finally I'd like to merge the support for freezer flags on workqueues. No comment here? : :-). I forgot why it was neccessary, but I was too shy to ask ;-). Just attach nice explanation when you attempt to merge it. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging the Suspend2 freezer implementation.
Hi. On Wed, 2005-02-09 at 09:32, Pavel Machek wrote: Hi! The main change involves the introduction of a new SYNCTHREAD flag. We use this to avoid deadlocking over processes that are running sys_sync and siblings. Processes that enter those routines get the flag added, and it's removed when they exit the sync routine. We then freeze in four stages: Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only? It's necessary for reliable freezing under I/O load. Signalling the non-sync threads first removes the race involved in some threads submitting I/O while others are trying to sync. Try doing a dd and a sync at the same time. The sync can take ages to return, worst case, sometimes not until the dd is completed. (Actually, try doing anything while a dd is running :) Okay, just attach this explanation when you are merging it otherwise I'll surely ask again... Okay. Finally I'd like to merge the support for freezer flags on workqueues. No comment here? : :-). I forgot why it was neccessary, but I was too shy to ask ;-). Just attach nice explanation when you attempt to merge it. Okay. Thanks! Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Merging the Suspend2 freezer implementation.
Hi Pavel. I'm keen to see if we can merge Suspend2's freezer implementation after 2.6.11. Does that conflict with any of your intended changes? If it doesn't, I'll submit a patch for review/merge as quickly as I can. The main change involves the introduction of a new SYNCTHREAD flag. We use this to avoid deadlocking over processes that are running sys_sync and siblings. Processes that enter those routines get the flag added, and it's removed when they exit the sync routine. We then freeze in four stages: 1) Freeze user space threads without SYNCTHREAD set; 2) Freeze user space threads with SYNCTHREAD set; 3) Run our own sys_sync in case no one else was syncing 4) Freeze kernel space threads without NOFREEZE set. I'd also like to look at your SMP support and see if we can improve compatibility there at the same time. Finally I'd like to merge the support for freezer flags on workqueues. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Merging the Suspend2 freezer implementation.
Hi Pavel. I'm keen to see if we can merge Suspend2's freezer implementation after 2.6.11. Does that conflict with any of your intended changes? If it doesn't, I'll submit a patch for review/merge as quickly as I can. The main change involves the introduction of a new SYNCTHREAD flag. We use this to avoid deadlocking over processes that are running sys_sync and siblings. Processes that enter those routines get the flag added, and it's removed when they exit the sync routine. We then freeze in four stages: 1) Freeze user space threads without SYNCTHREAD set; 2) Freeze user space threads with SYNCTHREAD set; 3) Run our own sys_sync in case no one else was syncing 4) Freeze kernel space threads without NOFREEZE set. I'd also like to look at your SMP support and see if we can improve compatibility there at the same time. Finally I'd like to merge the support for freezer flags on workqueues. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
