Messages in this thread | | | Date | Mon, 13 Jan 2003 17:26:38 +0100 | From | Jens Axboe <> | Subject | Re: any chance of 2.6.0-test*? |
| |
On Mon, Jan 13 2003, Terje Eggestad wrote: > On man, 2003-01-13 at 16:49, Jens Axboe wrote: > > On Mon, Jan 13 2003, Terje Eggestad wrote: > > > Considering that doing kernel development is hard enough, new > > > development is almost always done on uni processors kernels that do only > > > one thing at the time. Then when you base logic is OK, you move to a > > > SMP, which means (adding and) debugging you spin locks. > > > > Goto's aside, I find the above extremely bad advise. You should _always_ > > develop with smp and for smp from the very start, or you will most > > likely not get it right later on. With preempt, this becomes even more > > important. > > You should, and I do, *design* with smp in mind, and I throw in > smplock/unlonk as I go, but I tend to make first runs on a UP. > > I see your point on preemt, though. > You do first runs on SMP?
Always, if for nothing else than the benefit of a better debugging environment.
> > > Considering that fucking up spin locks are prone to corrupting your > > > machine, one very simple trick to makeing fewer mistakes to to have one, > > > and only one, unlock for every lock. > > > > Taking a spin lock twice will hard lock the machine, however on smp you > > will typically have the luxury of an nmi watchdog which will help you > > solve this quickly. Double unlock will oops immediately if you run with > > spin lock debugging (you probably should, if you are developing kernel > > code). > > I have the console on a serial port, and a terminal server. With kdb, > you can enter the kernel i kdb even when deadlocked.
Even if spinning with interrupt disabled?
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |