Date: Sat, 24 Nov 2012 14:10:13 -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: <50B145C5.8070503@mu.org> In-Reply-To: <CAJ-FndBeLvsgXQ4fskRwdZh2qaWbn7-LrCOmJTjPcfnbmD7aYg@mail.gmail.com> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <CAJ-FndBeLvsgXQ4fskRwdZh2qaWbn7-LrCOmJTjPcfnbmD7aYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. My goal is not to offend you, it's to explain why maintaining a stable API (which Linux somehow is doing better than us) is a worthwhile task. Maybe something is getting lost in my point here, but it's seriously not to offend, just show how it's done and how it can help us. thank you, -Alfred On 11/24/12 1:52 PM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 7:50 PM, Alfred Perlstein <bright@mu.org> wrote: >> On 11/24/12 11:30 AM, Mark Linimon wrote: >>> Alfred Perlstein wrote: >>>> According to this post I shouldn't touch anything that has to do with any >>>> SMP stuff until you complete your upcoming work because it will all be >>>> turned upside down. >>>> >>>> This is not what people should think about FreeBSD, it will drive >>>> developers away. >>>> >>>> Heck, I'm scared now to even write anything. >>>> >>>> -Alfred >>> Logical fallacy is fallacious. >>> >>> I've seen several people jump from "I'm getting pushback on foo" to >>> "nothing at all can be done" recently. It's bogus reasoning. >>> >>> My view is that the project is no longer in its infancy, where quick >>> and sometimes arbitrary changes could be made. That may have scaled >>> early on -- but now we have hundreds of developers, thousands of >>> contributors, and bazillions of users. Now we need consensus and buy-in >>> and roadmaps. >>> >>> Next, rather than compare who has done how much hard work and when >>> (and you both have), Attilio has been doing a lot of work on locking >>> over the past few years. If he (and possibly the people who have been >>> looking over his shoulder) have a view on how we should move forward, >>> I think they have earned the right to state it. >>> >>> Finally, IMHO, hyperbole can turn off developers too. >>> >> No offense to Attilio, the work, debugging, optimizations he's done have >> been beyond invaluable. > I will skip comments on your attitude, mindset, etc. (trying to let me > appear as the bad cop or play at "who is better") but just reply to > technical points. > >> Attilio's work on performance and reliability has been very helpful to me >> and many others. >> >> However, as someone who now is going to base kernel work on FreeBSD I find >> this change-for-the-sake-of-change to be completely terrifying. >> >> Well let's reiterate the content of Attilio's message: >> >> 1. lockmgr will be replaced/rototilled by something. > I would like to see it replaced by sx locks. > >> 2. sema will be replaced/rototilled by something. > I already said that it will be replaced by mtx + condvar. > >> 3. sleep mutexes and spin mutex will have API rototilled by something into >> something else. > I already said that I would like to see it replaced by rwlocks. > >> Why? >> >> So basically in the near future all locking primitives will change. Not >> based on feature parity with other OS, not based on preserving KPI. >> >> Just because it's "unclean". > Oh, this is just something you are saying. I didn't say it is > "unclean". I say it is completely wrong and completely redundant. Why > should we favourite code duplication? What is the reason? > > Why should we keep sema(9) interface when you can implement exactly > the same logic with a mutex and a condvar? There is a technical > reason? Can you make a real point out of it? Why we should keep > sema(9)? > >> Lockmgr has been a ... "pain" forever, it should go or at least never ever >> be used by anything but VFS. > My point on lockmgr() is that their basic mechanism is completely > redundant with sx. There are features they provide that are very > unique and that are very important for the buffer cache (disowning) or > VFS (interlock) but I think we can merge them with sx and be done with > it. > >> But back to the point, this isn't a roadmap, this is churn for the sake of >> churn. > These are milestones that we can break up in smaller pieces to make a > plan out of them. > >> For aesthetics. > No, this is for code maintenance. > >> It's not right and you know it. > Don't put words into my mouth. It is right and I know it. > > Ah and let me give you a piece of warning: bullying your opinions over > me is not going bringing you anywhere. I'm not a stupid doll you can > direct at your liking and I have a skin ticker enough to support my > ideas. > And finally I always try to give technical resons on things I propose, > despite your attitude to rework my words or entirely skip them. > Stop it. > > Attilio > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B145C5.8070503>