Messages in this thread |  | | From | Marty Fouts <> | Subject | RE: Anyone working on multi-threaded core files for 2.4 ? | Date | Fri, 29 Sep 2000 16:48:51 -0700 |
| |
> -----Original Message----- > From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] > Sent: Friday, September 29, 2000 2:08 PM > To: ilh@sls.lcs.mit.edu > Cc: viro@math.psu.edu; maillist@chello.nl; jcownie@etnus.com; > richardj_moore@uk.ibm.com; linux-kernel@vger.kernel.org > Subject: Re: Anyone working on multi-threaded core files for 2.4 ? > > > > > while the dump is taken? How about thread A coredumping, > half of the image > > > being already written and thread B (nowhere near the > kernel mode, mind > > > you) changing the data both in the area that is already > dumped and area > > > the still isn't? After that you can look at the dump and > notice absolutely > > > corrupted data structures - very effective in > misdirecting your attempts > > > to figure out what went wrong. > > > > Couldn't all threads be stopped before coredumping begins? > > Unless I am missing something doesn't a truncate of a file in > parallel also > yank the pages from under the dump too >
a "good enough" bit of coherence for dumping, it seems to me, can be met by insuring that none of the threads in the "process" are scheduled against a CPU during the dump. On a UP this can be relatively simple to do by making sure that each related thread is kept off the run queue while the dump occurs, since it is known that none of the non-failing threads were running when the dump started. On an MP you must also make sure that none of the threads are running on any of the other processors when the dump starts. Once all of the threads are stopped, then an "normal" dump is enough, augmented by (optionaly) dumping the thread-specific state (ie PCB and stack) of all of the threads in the "process."
Open question: whether or not to allow the remaining threads to continue once the dump is completed, to abort them, or to signal them. Probably should be run time configurable.
Marty
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |