Date: Wed, 02 Jan 2002 20:13:28 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, Peter Jeremy <peter.jeremy@alcatel.com.au>, Michal Mertl <mime@traveller.cz>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <3C33DA68.8E9700D4@mindspring.com> References: <XFMail.020102173003.jhb@FreeBSD.org> <200201030158.g031wWD61364@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > Let me put this in perspective, to show you how twisted the code > has become. > > * Because preemption can cause a thread to resume on a different cpu, > the per-cpu area pointer is not consistent and per-cpu variables > must be accessed atomically with the pointer. This is sorta bogus in general. CPU migration needs to be treated as an extraordinary event. This is why I suggested per CPU queues for scheduling, oh so long ago: it deals with the issue without causing all the complex cruft that Linux goes trough to try to get thread group affinity in the scheduler, and it makes it real easy to do negaffinity to maximize concurrency for a multithreaded program on a multi-CPU box. > * This means that obtaining 'curthread', for example, becomes relatively > non-cacheable in terms of code generation. Every time you get it you > have to re-obtain it. So a great deal of our code does this in order > to work around the lack of optimization: This has to be done anyway, or rather it's implicit anyway. I think this problem will be solving itself, eventually, and that eating the overhead is OK, for now, in the rare cases, it's really necessary. > :No. People need to write algorithms and not assume that implementation > :specifics about certain functions. There is a manpage (though it needs a bit > :of updating) for the critcal section stuff and it still accurately documents > :what the API is guaranteed to provide: protection from preemption. > > I don't understand what you are saying here. The algorithm I described > is platform independant (just as our spl mechanism was). What more can > one ask? It's great.. an API that everyone can depend on performing > well, exactly as advertised, across a multitude of platforms. I also think it's dangerous to do this. The contention domains are something I would rather be micromanaged, with a *lot* of assumptions about implementation: as many are necessary to get rid of the contention in all the common code cases -- or mitigate them as much as possible, anyway. PS: As to the "half the core locked up" comment: just implement, and whatever is best is what gets used, even if that means backing stuff out. FreeBSD has a long and glorious history of using this approach. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C33DA68.8E9700D4>