Date: Sat, 24 Nov 2012 17:03:54 -0800 From: Alfred Perlstein <bright@mu.org> To: attilio@FreeBSD.org Cc: Mark Linimon <linimon@lonesome.com>, Oleksandr Tymoshenko <gonzo@bluezbox.com>, arch@freebsd.org Subject: Re: [RFC] sema_wait_sig Message-ID: <50B16E7A.60900@mu.org> In-Reply-To: <CAJ-FndC%2BjHO2uKg%2Bd8GmzWGkQ8nZ6_iefgyGAeno0VqprR84Wg@mail.gmail.com> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <CAJ-FndBeLvsgXQ4fskRwdZh2qaWbn7-LrCOmJTjPcfnbmD7aYg@mail.gmail.com> <50B145C5.8070503@mu.org> <CAJ-FndC%2BjHO2uKg%2Bd8GmzWGkQ8nZ6_iefgyGAeno0VqprR84Wg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/24/12 4:38 PM, Attilio Rao wrote:
> 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.
Whoa, wait a second.
A user just proposed using the infrastructure to port linux drivers.
Additionally the following subsystems make use of sema(9):
inifiband stack (linux compat shim).
sysv ipc.
ata.
opensolaris compat shim.
xfs.
What would be the point of removing this KPI?
Those consumers would then just have to roll their own.
Wouldn't that lead to duplicate code?
176 sys/kern/kern_sema.c
It's not really a lot of code.
> 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).
I agree that lockmgr is a very dangerous beast. Whatever that can be
done to get rid of the complexity would be good.
If we could hide some of the lockmgr "features" behind a "I know what
i'm doing fence" or maybe a "only to be used with filesystem code" fence
that might be good.
-Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B16E7A.60900>