Date: Sun, 25 Nov 2012 00:38:25 +0000 From: Attilio Rao <attilio@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: Mark Linimon <linimon@lonesome.com>, Oleksandr Tymoshenko <gonzo@bluezbox.com>, arch@freebsd.org Subject: Re: [RFC] sema_wait_sig Message-ID: <CAJ-FndC%2BjHO2uKg%2Bd8GmzWGkQ8nZ6_iefgyGAeno0VqprR84Wg@mail.gmail.com> In-Reply-To: <50B145C5.8070503@mu.org> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <CAJ-FndBeLvsgXQ4fskRwdZh2qaWbn7-LrCOmJTjPcfnbmD7aYg@mail.gmail.com> <50B145C5.8070503@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 24, 2012 at 10:10 PM, Alfred Perlstein <bright@mu.org> wrote: > I don't understand why you are the one who is so upset. Your first email to > me implied that I had 0 smp experience. > > Let me explain why this rototilling is unneeded. > > Go download a copy of linux and observe the following: > spin_lock(&mb_cache_spinlock); > spin_unlock(&mb_cache_spinlock); > spin_lock_irqsave, spin_unlock_irqrestore > up() > down(dqio_mutex) > > Those apis have been available for a decade at least. > > I'll cut to the point on this. > > If you want to change HOW the underlying freebsd SMP api works to improve > performance, then please do! > > But if you want to change the actual KPI, then please realize that Linux SMP > does darn well with a KPI for SMP that's pretty much unchanged for nearly 10 > years. > > I would venture to say in this respect we've become what we used to mock > Linux for, an OS that gratuitously changes interfaces for the sake of what > is cool, versus what our vendors need. Keeping old mechanisms/duplicate/etc. around just because they existed 10 years ago is not a good reason once their KPI is not only redundant but also dangerous. And this seems to be your only "technical" reason opposed to my proposals. Using disown for lockmgr is something very dangerous which should not be used out of his specific case for the buffer cache. I really don't want to incourage its use out of that and I'm sure people can build very dangerous policies using it (this is just an example, but it explains my point, I think). Maybe my proposed changes of mtx against rwlock are a bit too extreme, I could understand that and I'm very open on changing my mind on it, but I don't understand how would be useful to keep lockmgr() and sema() around honestly. It is just a burden of code duplication (in some places) and dangerous KPI (in other). Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndC%2BjHO2uKg%2Bd8GmzWGkQ8nZ6_iefgyGAeno0VqprR84Wg>