:
:The main place I expect there to be trouble with is the swap-backed-vn device
:code. It does it's own clustering, aync/async-aware IO chaining, etc.
:
:> Greg
:
:Cheers,
:-Peter
I'm getting a new one. Sometimes during booting or rebooting the system
gets stuck in "biord". I have not
Greg Lehey wrote:
> On Wednesday, 30 June 1999 at 17:56:33 -0700, Matthew Dillon wrote:
> > So far I've run the latest buffer cache related fixes overnight on my
> > SMP test box without any problems.
> >
> > Is anyone still experiencing buffer-cache related problems with CURRENT
?
On Wednesday, 30 June 1999 at 17:56:33 -0700, Matthew Dillon wrote:
> So far I've run the latest buffer cache related fixes overnight on my
> SMP test box without any problems.
>
> Is anyone still experiencing buffer-cache related problems with CURRENT?
My problems are gone. But I'm
So far I've run the latest buffer cache related fixes overnight on my
SMP test box without any problems.
Is anyone still experiencing buffer-cache related problems with CURRENT?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
:The problem I see with this is teh resource load in times of critical
:resource shortage. If you need to suddenly generate a writable page..
:where does the page come from? If resources are not available, I guess you
:could just stall the write until the original page is reconstituted (after
:so
On Mon, 28 Jun 1999, Matthew Dillon wrote:
>
> :ok
> :
> : hadn't seen this one when I sent the previous email..
> :
> :Julian
> :
> :
> :On Mon, 28 Jun 1999, Matthew Dillon wrote:
> :
> :> :You are right that the buffer cache is very tricky. It is hard to
> :> :change it in ways that pr
:ok
:
:hadn't seen this one when I sent the previous email..
:
:Julian
:
:
:On Mon, 28 Jun 1999, Matthew Dillon wrote:
:
:> :You are right that the buffer cache is very tricky. It is hard to
:> :change it in ways that preserves functionality and performance.
:...
I've had a long pho
ok
hadn't seen this one when I sent the previous email..
Julian
On Mon, 28 Jun 1999, Matthew Dillon wrote:
> :You are right that the buffer cache is very tricky. It is hard to
> :change it in ways that preserves functionality and performance.
> :The port of my buffer locking code fr
D]>,
"John S. Dyson" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED], Greg Lehey <[EMAIL PROTECTED]>
Subject: Re: Found the startup panic - ccd ( patch included )
In-reply-to: Your message of "Mon, 28 Jun 1999 04:54:07 MST."
:You are right that the buffer cache is very tricky. It is hard to
:change it in ways that preserves functionality and performance.
:The port of my buffer locking code from BSD/OS has caused problems
:largely because of a different buffer cache implementation and
:especially SMP models between the
t;,
Mike Smith <[EMAIL PROTECTED]>,
"John S. Dyson" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Greg Lehey <[EMAIL PROTECTED]>
Subject: Re: Found the startup panic - ccd ( patch included )
References
:and B_WANTED code also required protection to avoid races), it would
:make a big performance improvement to just go make sure that all the
:BUF_ calls are already protected rather than needlessly add those splbio
:and splx calls.
:
: Kirk
Not as big as removing the lockmgr() code and r
:
:You are proposing replacing the current buffer locks with two separate
:locks, one for ownership and the other for I/O. Frankly, I do not find
:this simpler or easier to understand than what we have now. I also
The simplicity that I am requesting is that we do not add all these
BUF_KE
You are proposing replacing the current buffer locks with two separate
locks, one for ownership and the other for I/O. Frankly, I do not find
this simpler or easier to understand than what we have now. I also
take some issue with the cost of the lockmgr code. It is large, but
the critical paths t
:Certain places use B_CALL and have biodone() from the b_iodone routine,
:so we can't reliably use B_ASYNC as an indicator of needing to reassign
:to LK_KERNPROC. We have to do it on a case-by-case basis.
:
:It's easier to do cluster_head processing at the point it's gathered
:rather than in BUF_
Kirk McKusick wrote:
[..]
I've been tinkering around for a while and think I have at least a
partial fix for the remaining problems.
Certain places use B_CALL and have biodone() from the b_iodone routine,
so we can't reliably use B_ASYNC as an indicator of needing to reassign
to LK_KERNPROC. We
AIL PROTECTED]>, Peter Wemm <[EMAIL PROTECTED]>,
"John S. Dyson" <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Greg Lehey <[EMAIL PROTECTED]>
Subject: Re: Found the startup panic - ccd
I hate reeplying to myself, especially when it's to tell me that I'm an
idiot.. I just realised (i think) that what I suggest below is exactly
what you are doing...
julian
On Mon, 28 Jun 1999, Julian Elischer wrote:
>
>
> On Sun, 27 Jun 1999, Kirk McKusick wrote:
>
> > I see that Peter ha
Peter Wemm wrote:
[..]
> Also, the swap IO clustering/chainging etc is troubled since it turns on
> and off B_ASYNC and does it's own freeing and waiting. I haven't got my
> brain around it yet but I don't think it's going to be too hard to fix.
[..]
This is a false alarm, it's not directly swap
Greg Lehey wrote:
> On Monday, 28 June 1999 at 16:36:31 +0800, Peter Wemm wrote:
> > Kirk McKusick wrote:
> > [..]
> >> Greg Lehey has sent me a panic with the buffer locking in the NFS code.
> >> I am too tired to attack it tonight, but will look at it in the morning.
> >
> > I might have a look
On Monday, 28 June 1999 at 16:36:31 +0800, Peter Wemm wrote:
> Kirk McKusick wrote:
> [..]
> Re: kern_lock.c - looks like a reasonable fix. There isn't much point
> panicing for a poll.
>
>> I do not see the problem that you are pointing out with missing
>> BUF_KERNPROC in cluster_callback, but i
Kirk McKusick wrote:
[..]
Re: kern_lock.c - looks like a reasonable fix. There isn't much point
panicing for a poll.
> I do not see the problem that you are pointing out with missing
> BUF_KERNPROC in cluster_callback, but it is well past midnight,
> so I may not be thinking clearly.
No, you ar
:On the subject of BUF_KERNPROC, this must be done as I have coded
:it, not later in biodone. The problem is when the filesystem does
:a readahead. It starts the I/O on the buffer that it really wants,
:...
:recursive locking is allowed, then it will get the buffer (since
:it holds the exclusive l
On Sun, 27 Jun 1999, Kirk McKusick wrote:
> I see that Peter has already committed it.
>
> On the subject of BUF_KERNPROC, this must be done as I have coded
> it, not later in biodone. The problem is when the filesystem does
> a readahead. It starts the I/O on the buffer that it really wants,
gt;,
"John S. Dyson" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Found the startup panic - ccd ( patch included )
:I'm seeing the same thing here.
:
: Alan
:
:P.S. Julia
25 matches
Mail list logo
