On Sun, 24 Feb 2002, Bruce Evans wrote:
>
> It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
> and dificult to untangle from my other patches. I posted these partial
> ones to attempt to inhibit() recomplication of the current critical*
> functions in directions that I
On Sat, 23 Feb 2002, Alfred Perlstein wrote:
> Usually when I see diff(1) output from you I usually expect a commit
> within the next half hour or so, I just wanted to make myself clear on
> the issue. No worries. :)
>
> Yes, and hopefully JeffR's allocator will fix our problems, that is if
>
I'm going to wait until tomorrow before posting it. I have a bunch of
cleanup to do.
Bruce, your sys.dif was *invaluable*! It would have taken me a lot
longer to figure out the interrupt disablement requirement around
the icu_lock, and the statclock and hardclock forwarding
Alfred Perlstein wrote:
> * Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
> > This is approximately what I am thinking. Note that this gives us the
> > flexibility to create a larger infrastructure around the bucket cache,
> > such as implement per-cpu caches and so on and
Jake Burkholder wrote:
> Jeff Roberson (jeff@) has been working on a slab allocator that goes
> a long way to making malloc(), free() and the zone allocator not require
> giant. I've reviewed what he's got so far and it looks pretty damn good
> to me, I'll see about getting him to post it. He's
On Sat, Feb 23, 2002 at 03:12:36PM -0800, Matthew Dillon wrote:
>
> :OTOH, A per CPU bucket list means no bucket mtx would be necessary;
> :without that, it's just replacing one type of contention for another,
> :I think, until you start making mutex selection indeterminate. 8^(.
> :
> :Really,
:> :(the ICU masks pending interrupts).
:> :
:> :Bruce
:>
:> Ok, I have most of it coded up. Could you explain what 'spending'
:> was for?
:
:Like the SWI bits in ipending in RELENG_4. In RELENG_4, we have to pass
:around all the bits to spl*(), so we had to pack them in at least some
:
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> :ipending here works much as in RELENG_4. It is ORed into by sched_ithd()
> :if curthread->td_critnest != 0. Nothing special is needed for pci
> :(the ICU masks pending interrupts).
> :
> :Bruce
>
> Ok, I have most of it coded up. Could you expl
:
:On Sat, 23 Feb 2002, Matthew Dillon wrote:
:
:> :It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
:> :and dificult to untangle from my other patches. I posted these partial
:> :ones to attempt to inhibit() recomplication of the current critical*
:> :functions in direc
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> :It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
> :and dificult to untangle from my other patches. I posted these partial
> :ones to attempt to inhibit() recomplication of the current critical*
> :functions in directions tha
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> Bruce, I've looked at the vector assembly and it looks like cleaning
> up critical_enter() and critical_exit() for i386 ought to be simple.
>
> If you have a complete patch set I would like to see it posted for
> review or comitted, or
:It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
:and dificult to untangle from my other patches. I posted these partial
:ones to attempt to inhibit() recomplication of the current critical*
:functions in directions that I don't want to go :-).
:...
:
:ipending here work
:
:On Sat, 23 Feb 2002, Matthew Dillon wrote:
:
:> :My version of it does less than this. I only use it to help implement
:> :spinlocks.
:>
:> You put together infrastructure to deal with pending pci interrupts?
:> If so, then why not commit it (or at least commit a version #ifdef'd
:>
Bruce, I've looked at the vector assembly and it looks like cleaning
up critical_enter() and critical_exit() for i386 ought to be simple.
If you have a complete patch set I would like to see it posted for
review or comitted, or if you don't want to deal with the commit I
woul
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> :My version of it does less than this. I only use it to help implement
> :spinlocks.
>
> You put together infrastructure to deal with pending pci interrupts?
> If so, then why not commit it (or at least commit a version #ifdef'd
> for the
* Matthew Dillon <[EMAIL PROTECTED]> [020223 16:41] wrote:
>
> :
> :* Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
> :> This is approximately what I am thinking. Note that this gives us the
> :> flexibility to create a larger infrastructure around the bucket cache,
> :> s
:
:* Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
:> This is approximately what I am thinking. Note that this gives us the
:> flexibility to create a larger infrastructure around the bucket cache,
:> such as implement per-cpu caches and so on and so forth. What I have
:>
* Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
> This is approximately what I am thinking. Note that this gives us the
> flexibility to create a larger infrastructure around the bucket cache,
> such as implement per-cpu caches and so on and so forth. What I have
> her
:My version of it does less than this. I only use it to help implement
:spinlocks.
You put together infrastructure to deal with pending pci interrupts?
If so, then why not commit it (or at least commit a version #ifdef'd
for the i386 architecture).
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> critical_enter() isn't much better then a mutex. It can
> be optimized to get rid of the inline cli & sti however. Actually, it
> can be optimized trivially for i386, all we have to do is check the
> critical nesting count from the in
Apparently, On Sat, Feb 23, 2002 at 02:43:35PM -0800,
Matthew Dillon said words to the effect of;
> This is approximately what I am thinking. Note that this gives us the
> flexibility to create a larger infrastructure around the bucket cache,
> such as implement per-cpu cache
:OTOH, A per CPU bucket list means no bucket mtx would be necessary;
:without that, it's just replacing one type of contention for another,
:I think, until you start making mutex selection indeterminate. 8^(.
:
:Really, this delayed freeing idea is starting to get uglier than
:just going to per
Matthew Dillon wrote:
> This is approximately what I am thinking. Note that this gives us the
> flexibility to create a larger infrastructure around the bucket cache,
> such as implement per-cpu caches and so on and so forth. What I have
> here is the minimal implementation.
Uh,
23 matches
Mail list logo
