Date: Thu, 5 Oct 2000 23:29:04 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Terry Lambert <tlambert@primenet.com> Cc: Mark Murray <mark@grondar.za>, Jake Burkholder <jburkhol@HOME.COM>, Boris Popov <bp@butya.kz>, freebsd-smp@FreeBSD.ORG Subject: Re: Problems with kthread_exit() and SMPng Message-ID: <20001005232904.Z27736@fw.wintelcom.net> In-Reply-To: <200010060522.WAA22938@usr02.primenet.com>; from tlambert@primenet.com on Fri, Oct 06, 2000 at 05:22:06AM %2B0000 References: <20001005151504.K27736@fw.wintelcom.net> <200010060522.WAA22938@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert@primenet.com> [001005 22:22] wrote: > > One of the options for fixing kernel logging under SMP was to have > > a very simple queing mechanism to send the messages to a kernel > > thread that would be repsoncible for the output. > > I followed that discussion when it was taking place. It makes > sense that one would queue any IPC between any part of a kernel > and the kernel thread that is responsible for serially processing > the IPC request. > > So a more generic mechanism for queueing messages in the kernel > is probably called for (you may rememebr my call for this back > when you introduced your limited purpose API which did basically > this type of queueuing). What API? I honestly don't remeber introducing a message passing api into freebsd. > It makese sense to protect the queues with a mutex per queue, for > the purposes of enqueueng and dequeueing these messages. Yup. > > You see, the problem with logging is that the logging calls are in > > a lot of weird places, nevermind critical ones like panic, there > > needs to be a special relationship between the logging kthread and > > the system which may be difficult to set up. > > I disagree with this completely. There does not need to be a > "special relationship"; special relationships are anathema. Look > at the special relationship between libkvm and kernel structures > (a data interface, as you appear to be suggesting for logging), > and the hell it hath wrought. As people continue to extend things > rather than fixing old, broken things, this problem, and problems > like it, will continue to haunt us. Er, you can't have a panic stop the messaging thread from outputting the panic message, well you could but it would make debugging things a bit more difficult. > > You also have to take into account that the output method of > > the driver might block therefore we need to hand off the > > blocking to someone else. > > It is not permissable to block while holding a mutex; I've played > this song before, and there's no need to repeat the whole thing > in this thread. Yes, that's the idea, the kthread that recieves the message will do the call into the console driver so that it can block inside of it while letting the queing process just aquire a spinlock on the queue head (no long term blocking). -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001005232904.Z27736>