Re: [RFC][PATCH 5/14] Introduce union stack
On Mon, 14 May 2007 13:23:06 -0700, Badari Pulavarty wrote:
> > + while (fs) {
> > + locked = union_trylock(fs->root);
> > + if (!locked)
> > + goto loop1;
> > + locked = union_trylock(fs->altroot);
> > + if (!locked)
> > + goto loop2;
> > + locked = union_trylock(fs->pwd);
> > + if (!locked)
> > + goto loop3;
> > + break;
> > + loop3:
> > + union_unlock(fs->altroot);
> > + loop2:
> > + union_unlock(fs->root);
> > + loop1:
> > + read_unlock(&fs->lock);
> > + UM_DEBUG_LOCK("Failed to get all semaphores in fs_struct!\n");
> > + cpu_relax();
> > + read_lock(&fs->lock);
> > + continue;
>
> Nit.. why "continue" ?
>
> > + }
> > + BUG_ON(!fs);
How about getting rid of the gotos:
while (fs) {
locked = union_trylock(fs->root);
if (locked) {
locked = union_trylock(fs->altroot);
if (locked) {
locked = union_trylock(fs->pwd);
if (locked)
break;
else {
union_unlock(fs->altroot);
union_unlock(fs->root);
}
else
union_unlock(fs->root);
}
}
read_unlock(&fs->lock);
UM_DEBUG_LOCK("Failed to get all semaphores in fs_struct!\n");
cpu_relax();
read_lock(&fs->lock);
}
BUG_ON(!fs);
It's the same number of lines. Shorter if you get rid of the "locked"
variable.
-Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, 2 Mar 2005 14:21:38 -0800 (PST), Linus Torvalds wrote: > The reason I put a shorter timeframe on the "all-even" kernel is because I > don't want developers to be too itchy and sitting on stuff for too long if > they did something slightly bigger. In theory, the longer the better > there, but in practice this release numbering is still nothing but a hint > of the _intent_ of the developers - it's still not a guarantee of "we > fixed all bugs", and anybody who expects that (and tries to avoid all odd > release entirely) is just setting himself up for not testing - and thus > bugs. > > Comments? You still haven't solved the problem of only a small group using the development kernels. Until a "stable" kernel is released, the majority of kernel compilers will avoid any development kernel (even on this mailing list!). Two suggestions (one or both could be implemented): How about appointing maintainers for 2.6.N kernels, whose responsibility is apply stability and security patches for 3 months AND until 2.6.N+3 is released. So a series of 2.6.11.M kernels will appear until 2.6.14 and 2.6.11 is at least 3 months old. This would given kernel developers experience with such releases, but without the job being for the life of the developer. Also, add a list to the kernel.org web page about which kernels are considered stable. Listed stable kernels are those who have been released for at least two weeks. -Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network speed Linux-2.6.10
On Wed, 02 Mar 2005 01:02:50 +, Baruch Even wrote: > > Might this be related to the broken BicTCP implementations in the 2.6.6+ > > kernels? A fix was added around 2.6.11-rc3 or 4. > > Unlikely, the problem with BIC would have shown itself only at high > speeds over long latency links, not over a lan connection. I only mentioned the possibility because I saw the same profile given by the PDF (the link was mentioned in the patch) while downloading gnoppix via my cable modem. The oscillations of speed varied from 40K to 500+K. The average ended up around 270K. (I was using wget for the download). -Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network speed Linux-2.6.10
On Tue, 1 Mar 2005 14:29:24 -0500 (EST), linux-os wrote: > Intel NIC e100 device driver. Two identical machines. > Private network, no other devices. Connected using a Netgear switch. > Test data is the same thing sent from memory on one machine > to a discard server on another, using TCP/IP SOCK_STREAM. > > If I set both machines to auto-negotiation OFF and half duplex, > I get about 9 to 9.5 megabytes/second across the private wire > network. > > If I set one machine to full duplex and the other to half-duplex > I get 10 to 11 megabytes/second transfer across the network, > regardless of direction. > > If I set both machines to auto-negotiation OFF and full duplex, > I get 300 to 400 kilobytes/second regardless of the direction. Might this be related to the broken BicTCP implementations in the 2.6.6+ kernels? A fix was added around 2.6.11-rc3 or 4. -Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
