Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Larry McVoy]

You don't need the tags, use dates.  You can get the date range you want 
with an rlog of the ChangeSet file and then use those dates.

On Mon, Jul 21, 2003 at 12:02:26PM -0700, Mike Fedyk wrote:
> ----- Forwarded message from Andrea Arcangeli <andrea@suse.de> -----
> 
> Delivery-date: Mon, 21 Jul 2003 11:52:43 -0700
> Date: Mon, 21 Jul 2003 12:20:33 -0400
> From: Andrea Arcangeli <andrea@suse.de>
> To: Stephan von Krawczynski <skraw@ithnet.com>
> Cc: marcelo@conectiva.com.br, mason@suse.com, riel@redhat.com,
> 	linux-kernel@vger.kernel.org, maillist@jg555.com
> Subject: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)
> User-Agent: Mutt/1.4i
> X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49  C012 DFA1 686E 68B9 CB43
> X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC  C0 4B 81 1D 8C 15 C8 E5
> X-Mailing-List: linux-kernel@vger.kernel.org
> X-Spam-Status: No, hits=-3.1 required=5.0
> 	tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,
> 	      RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT,
> 	      X_MAILING_LIST
> 	version=2.55
> X-Spam-Level: 
> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
> 
> On Mon, Jul 21, 2003 at 05:05:17PM +0200, Stephan von Krawczynski wrote:
> > On Mon, 21 Jul 2003 10:49:06 +0200
> > Stephan von Krawczynski <skraw@ithnet.com> wrote:
> > 
> > > On Fri, 18 Jul 2003 11:14:15 -0300 (BRT)
> > > Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
> > > 
> > > > 
> > > > I have just started stress testing a 8way OSDL box to see if I can
> > > > reproduce the problem. I'm using pre6+axboes BH_Sync patch.
> > > > 
> > > > I'm running 50 dbench clients on aic7xxx (ext2) and 50 dbench clients on
> > > > DAC960 (ext3). Lets see what happens.
> > > > 
> > > > After lunch I'll keep looking at the oopses. During the morning I only had
> > > > time to setup the OSDL box and start the tests.
> > > 
> > > Hello Marcelo,
> > > 
> > > have you seen anything in your tests? My box just froze again after 3 days
> > > during NFS action. This was with pre6, I am switching over to pre7.
> > 
> > I managed to freeze the pre7 box within these few hours. There was no nfs
> > involved, only tar-to-tape.
> > I switched back to 2.4.21 to see if it is still stable.
> > Is there a possibility that the i/o-scheduler has another flaw somewhere (just
> > like during mount previously) ...
> 
> is it a scsi tape? Is the tape always involved? there are st.c updates
> between 2.4.21 to 22pre7. you can try to back them out.
> 
> If only the BKCVS would provide the tags in all files and not only in
> the file ChangeSets it would be very easy again to extract all the st.c
> updates. What happened to the BKCVS, why aren't the tags present in all
> the files anymore? Is it a mistake or intentional?
> 
> You should also provide a SYSRQ+P/T of the hang or we can't debug it at
> all.
> 
> Andrea
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> ----- End forwarded message -----

-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Andrea Arcangeli]

Hi Larry,

On Mon, Jul 21, 2003 at 12:45:14PM -0700, Larry McVoy wrote:
> You don't need the tags, use dates.  You can get the date range you want 
> with an rlog of the ChangeSet file and then use those dates.

I realized I could do this, and it can of course be automated with an
additional bkcvs specific hack in cvsps. But the tag in every file would
have kept the functionality generic with the already available -r
option, and since I can't see any downside in the tag in the files, I
prefer that generic way.

But if you're sure the tags aren't coming back we can start adding the
automation to cvsps.

thanks,

Andrea

Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Larry McVoy]

On Mon, Jul 21, 2003 at 05:21:55PM -0400, Andrea Arcangeli wrote:
> Hi Larry,
> 
> On Mon, Jul 21, 2003 at 12:45:14PM -0700, Larry McVoy wrote:
> > You don't need the tags, use dates.  You can get the date range you want 
> > with an rlog of the ChangeSet file and then use those dates.
> 
> I realized I could do this, and it can of course be automated with an
> additional bkcvs specific hack in cvsps. But the tag in every file would
> have kept the functionality generic with the already available -r
> option, and since I can't see any downside in the tag in the files, I
> prefer that generic way.

The tags means that each file gets modified for each tag and then we have
to transfer the whole tree after a tag.  It thrashes the hell out of the
disk too, for no good reason.

Also note that there are nowhere near as many tags as there are commits
in the CVS tree.  So by using tags you are restricting yourself to coarse
granularity in your bug hunts.

> But if you're sure the tags aren't coming back we can start adding the
> automation to cvsps.

Please do, we're not adding the tags.  
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Andrea Arcangeli]

On Mon, Jul 21, 2003 at 02:31:59PM -0700, Larry McVoy wrote:
> On Mon, Jul 21, 2003 at 05:21:55PM -0400, Andrea Arcangeli wrote:
> > Hi Larry,
> > 
> > On Mon, Jul 21, 2003 at 12:45:14PM -0700, Larry McVoy wrote:
> > > You don't need the tags, use dates.  You can get the date range you want 
> > > with an rlog of the ChangeSet file and then use those dates.
> > 
> > I realized I could do this, and it can of course be automated with an
> > additional bkcvs specific hack in cvsps. But the tag in every file would
> > have kept the functionality generic with the already available -r
> > option, and since I can't see any downside in the tag in the files, I
> > prefer that generic way.
> 
> The tags means that each file gets modified for each tag and then we have
> to transfer the whole tree after a tag.  It thrashes the hell out of the
> disk too, for no good reason.
> 
> Also note that there are nowhere near as many tags as there are commits
> in the CVS tree.  So by using tags you are restricting yourself to coarse
> granularity in your bug hunts.

the granularity wasn't the issue, I need this feature anyways out of
cvsps (cvsps is exactly the thing that generates the changesets out of
the coarse granularity of the tags). the checkout/rsync being more
expensive sounds a fair enough argument for implementing the feature in
cvsps where it will be zero write cost.

since we're talking about bkcvs, I also would have a feature wish for
the repository export in rsync.kernel.org: would it be possible to
export a sequence number increased once before a transfer, and increased
a second time after the tree is coherent again? When the sequence number
is even and it didn't change before and after the rsync, we'll know the
current status is coherent and we don't need to repeat the rsync (after
some delay). Or is there any other mechanism that guarantees to get a
coherent repository out of rsync?

thanks,

Andrea

Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Larry McVoy]

On Mon, Jul 21, 2003 at 06:00:00PM -0400, Andrea Arcangeli wrote:
> since we're talking about bkcvs, I also would have a feature wish for
> the repository export in rsync.kernel.org: would it be possible to
> export a sequence number increased once before a transfer

I don't manage the rsync trees, HPA does that.  Peter?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Andrea Arcangeli]

Hi,

On Mon, Jul 21, 2003 at 06:00:00PM -0400, Andrea Arcangeli wrote:
> On Mon, Jul 21, 2003 at 02:31:59PM -0700, Larry McVoy wrote:
> > On Mon, Jul 21, 2003 at 05:21:55PM -0400, Andrea Arcangeli wrote:
> > > Hi Larry,
> > > 
> > > On Mon, Jul 21, 2003 at 12:45:14PM -0700, Larry McVoy wrote:
> > > > You don't need the tags, use dates.  You can get the date range you want 
> > > > with an rlog of the ChangeSet file and then use those dates.
> > > 
> > > I realized I could do this, and it can of course be automated with an
> > > additional bkcvs specific hack in cvsps. But the tag in every file would
> > > have kept the functionality generic with the already available -r
> > > option, and since I can't see any downside in the tag in the files, I
> > > prefer that generic way.
> > 
> > The tags means that each file gets modified for each tag and then we have
> > to transfer the whole tree after a tag.  It thrashes the hell out of the
> > disk too, for no good reason.
> > 
> > Also note that there are nowhere near as many tags as there are commits
> > in the CVS tree.  So by using tags you are restricting yourself to coarse
> > granularity in your bug hunts.
> 
> the granularity wasn't the issue, I need this feature anyways out of
> cvsps (cvsps is exactly the thing that generates the changesets out of
> the coarse granularity of the tags). the checkout/rsync being more
> expensive sounds a fair enough argument for implementing the feature in
> cvsps where it will be zero write cost.

while writing the code to do it, I noticed the heuristic was already
there in cvsps ;), and it is generic (not hardwired to the ChangeSet
file). I had bad luck diffing with -r v2_4_22-pre3 (which is missing
from the changeset file too, so I guess the info is missing in bitkeeper
as well, not just bkcvs).  Infact probably it's a long time that you
dropped the tags from all files, and I noticed only now after getting
the error diffing against 22pre3 ;).

> since we're talking about bkcvs, I also would have a feature wish for
> the repository export in rsync.kernel.org: would it be possible to
> export a sequence number increased once before a transfer, and increased
> a second time after the tree is coherent again? When the sequence number
> is even and it didn't change before and after the rsync, we'll know the
> current status is coherent and we don't need to repeat the rsync (after
> some delay). Or is there any other mechanism that guarantees to get a
> coherent repository out of rsync?

Peter, any suggestion on this? Larry said it's all on your side, so I
assume you're running bkcvs yourself, or Larry is already providing you
a locking mechanism that serializes against bkcvs and that allows you
to fetch a coherent of the cvs repository. w/o this last locking bit
that allows to export a coherent copy of the repository, I can't easily
automate the stuff based on a local repository and I've to switch to the
remote one, despite having it local is more flexible (and much faster
for local browsing) and rsync -z is faster.

Many thanks again to both of you and last but not the least to David
Mansfiel (cvsps author).

Andrea

Re: Fwd: Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)

[Andrea Arcangeli]

Hi,

On Tue, Jul 29, 2003 at 11:28:21AM +0200, Andrea Arcangeli wrote:
> Peter, any suggestion on this? Larry said it's all on your side, so I
> assume you're running bkcvs yourself, or Larry is already providing you
> a locking mechanism that serializes against bkcvs and that allows you
> to fetch a coherent of the cvs repository. w/o this last locking bit
> that allows to export a coherent copy of the repository, I can't easily
> automate the stuff based on a local repository and I've to switch to the
> remote one, despite having it local is more flexible (and much faster
> for local browsing) and rsync -z is faster.

Any news on this? I'm still looking into a way to rsync a coherenty copy
of the cvs repository.

Andrea