On 23-Feb-02 Alfred Perlstein wrote:
> * Matthew Dillon <[EMAIL PROTECTED]> [020223 12:51] wrote:
>>
>> :Here is the most up-to-date version of pgrp/session lock (at Change 6700):
>> :
>> :http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz
>> :
>> :I would like to commit this on the next
:> I don't think we want to make sched_lock any more complex then it
:> already is, so at least for the foreseeable future we are not
:> going to be able to actually execute an interrupt handler until
:> the sched_lock is released in (typically) msleep(). I am rather
:
:Well, my k
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 Sun, 24 Feb 2002, Matthew Dillon wrote:
> :cpu_switch() certainly needs to do this if it can be called with the
> :interrupt enable flag[s] in different states. I need the sti's (actually
> :enable_intr()'s because I don't want fast interrupts to be disabled
> :during context switches. This
:> up. One of the best things about this patch set is that it is really
:> flexible. We should be able to really make interrupts fly. In fact,
:> it should even be possible for one cpu to steal another cpu's pending
:> interrupt(s) fairly trivially, without having to resort to I
On Sun, 24 Feb 2002, Matthew Dillon wrote:
> 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 issues (which I
> got working by the way!
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,
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.
:All these per-subsystem free-lists are making me nervous in both
:complexity and wasted code...
:
:Ok, instead of keeping all these per-subsystem free-lists here's what
:we do:
:
:In kern_malloc:free() right at the point of
: if (size > MAXALLOCSAVE) we check if we have Giant or not.
:if we
Alfred Perlstein wrote:
> All these per-subsystem free-lists are making me nervous in both
> complexity and wasted code...
Me too.
> Ok, instead of keeping all these per-subsystem free-lists here's what
> we do:
>
> In kern_malloc:free() right at the point of
> if (size > MAXALLOCSAVE) we che
31 matches
Mail list logo
