Re: PATCH Multithreaded core dumps for the 2.5.17 kernel was ....RE: PATCH Multithreaded core dump support for the 2.5.14 (and 15) kernel.

[Mark Gross <mgross@unix-os.sc.intel.com>]

On Wednesday 22 May 2002 10:17 am, Pavel Machek wrote:
> Hi
>
> > Nice. This also closes another issue pointed out: freezing
> > a process while it is holding the mmap_sem, which may be needed later
> > while collecting thread registers on IA64.
> >
> > Now that Linus has accepted Pavel's swsusp, do you have any thoughts
> > on using Pavel's scheme to freeze processes?
>
> I attempt half of signal delivery to the threads, but that should not be
> a problem. Currently freezing stuff is there only for CONFIG_SWSUSP case,
> but it is probably small enough to be there unconditionaly.
> 								Pavel

I think that although my tcore_suspend_threads and Pavel's freeze_processes 
have similar results, I don't think using Pavel's approach for the core dump 
is a good idea.

1) SMP is a stability problem.  I want TCore to work for 2.4x kernels  
soon. 
2) To avoid the issues with I/O bound threads waking up, Pavel's design waits 
for the signal to get them running and then drops them in the "refrigerator". 
 
My design is explicitly going for the most accurate core dump it can.  
If I need to wait for processes to wake up and get frozen on a large SMB box 
then we can loose a lot of accuracy.

I do however; think Pavels work could benefit from using some of my approach. 
 It might simplify all those places where his patch tests p->state | 
PK_FREEZE and then calls  refrigerator.   It perhaps make it work better for 
SMP if software suspend is considered a usefull feature on a SMP systems.

It would still need to wait for all the I/O bound processes to finish their 
pending I/O but, I think it could be made to work.

--mgross