Date: Sun, 23 Jul 2000 16:09:12 -0400 From: hspio@worldnet.att.net To: hackers@FreeBSD.ORG Subject: Remove Message-ID: <397B18A8.5713.3D69341@localhost> In-Reply-To: <bulk.75304.20000723072226@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Jul 2000, at 7:22, freebsd-hackers-digest wrote: > > freebsd-hackers-digest Sunday, July 23 2000 Volume 04 : Number 901 > > > > In this issue: > Re: Multiple ro mounts of vinum volume > Re: Multiple ro mounts of vinum volume > Re: Intel 840 Chipset Discontinue > Re: sysutils/memtest and FreeBSD > Re: /etc/defaults/make.conf:LEAPSECONDS= true? > Re: clearing pages in the idle loop > Re: sysutils/memtest and FreeBSD > 4.1-RC + SBLive + ECC = NMI > Re: 4.1-RC + SBLive + ECC = NMI > 4.0-RELEASE/tail/st_rdev > Re: minherit(2) API > > ---------------------------------------------------------------------- > > Date: Sat, 22 Jul 2000 15:52:38 +0200 > From: Bernd Walter <ticso@cicely8.cicely.de> > Subject: Re: Multiple ro mounts of vinum volume > > On Thu, Jul 20, 2000 at 06:33:42PM +0930, Greg Lehey wrote: > > On Thursday, 20 July 2000 at 9:55:13 +0100, Geoff Buckingham wrote: > > A thing that might bite you here is that ufs is currently limited to 1 > > TB per volume. Vinum doesn't have that restriction: if you want to > > create a 20 TB volume, and you know how to use the space, Vinum should > > work. The problem with ufs is that the block numbers in the inodes > > are 32 bit signed values. With 512 byte sectors, the only we can do > > it, that means a total address space of 2**9 * 2*31, or 1 TB. At some > > time I suspect we're going to need to fix that. > > Block numbers in inodes are not physical blocks (named sectorsize in > UFS source) but logical which is equal to the size of an fragment and > thus defaults to 1k. > The problem is the driver and VM layer. > If vinum would simulate 2k "physical" blocksize it may go up to 4TB > if you set the fragment size to 4k. I don't know if any > middle calculation might harm or VM is missbehaving. > The point I never digged deeper here is because you already sugested > changing the driver layer to 64bit byte numbers which was accepted if > I remember right. > Some of the systems I've setup are near this Limit so I spend some time > to find out where the show stoppers are. > > - -- > B.Walter COSMO-Project http://www.cosmo-project.de > ticso@cicely.de Usergroup info@cosmo-project.de > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 22 Jul 2000 16:01:59 +0200 > From: Poul-Henning Kamp <phk@critter.freebsd.dk> > Subject: Re: Multiple ro mounts of vinum volume > > In message <20000722155238.A27452@cicely8.cicely.de>, Bernd Walter writes: > > >The point I never digged deeper here is because you already sugested > >changing the driver layer to 64bit byte numbers which was accepted if > >I remember right. > > Yes, I have this on my plate. > > - -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 22 Jul 2000 10:22:08 -0400 (EDT) > From: Andrew Gallatin <gallatin@cs.duke.edu> > Subject: Re: Intel 840 Chipset Discontinue > > Mike Smith writes: > > > I was told by several of my distributors that all motherboards based off > > > of the Intel 840 chipset are being discontinued. That means the Supermicro > > > PIIDM3 and PIIIDME, and any other 840 board. > > Hurray! ;-) > > > I have mixed feelings about this, but on the whole I think it's probably > > for the best. I've had really patchy results with the i840, and > > performance hasn't been impressive. > > While, on the other hand, I cannot say enough good things about the > performance of our Dell PowerEdge 2400 & 4400 machines (both use RCC > chipsets). What else can you say about machines that will serve NFS > over via gig ether at over 70MB/sec and not break a sweat ;) > > > > Supermicro has two new boards, 370DL3 and 370DLE. Identical in specs to > > > the 840 boards, but using some kind of "ServerWork LE" chipset. However, I > > > have also been hearing bad news about these boards as well. > > > > We've had some issues with the RCC chipsets in Dell systems, yes. > > All of these are now resolved, aren't they? > > > > Has anyone worked with these boards? Supermicro SAYS that they work fine > > > under Linux and Solaris. However, one of my distributors says thay they > > > are extremely touchy when it comes to memory. Only Registered PC133 ECC > > > memory will work. > > This memory requirement probably explains why they perform so well ;) > The RCC chipsets, especially those which use interleaved memory like > in the PE4400, have stunningly good I/O bandwidth for a PC. They have > over 440MB/sec of I/O bandwidth to a 64-bit 66MHz PCI bus (I've > actually measured it, yes). They run gig ether at 950Mb/sec with > stock kernels and I've run protype Myrinet boards at over 2Gb/sec > end-to-end with TCP using the zero-copy sockets framework that Ken > Merry has been talking about. > > > > If someone at freebsd.org wants to seriously test these boards, let me > > > know, and I'll donate one. Without the 840 boards, server configs are now > > > back to the 440GX days! > > We've got a big purchase coming up & I'd love to get my hands on one > of them for testing, but FreeBSD test labs should get priority. > FWIW, I'm mainly an alpha port committer, but I'm the one who fixed > the RCC peer bus probing issues when we got our Dell 2400 a few months > back.. > > Anyway, we're looking to replace some of our cluster & would be > looking for 16-24 nodes of them. We were originally planning to get > Alpha DS10Ls, but the availability of RCC chipsets in a small form > factor may change our minds as the RCC chipset is the only thing that > can compete with the alpha's Tsunami chipset for I/O bandwidth. > > Do you know of anybody building 1U or 2U rackmount systems for a > reasonable price ($2000/node or less) around these motherboards? It > looks like most integrators are using the L44GX & its broken 32-bit > 66MHz slot which runs at the wrong voltage (Myrinet claims they're > violating the PCI spec). > > Cheers, > > Drew > > - ------------------------------------------------------------------------------ > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: gallatin@cs.duke.edu > Department of Computer Science Phone: (919) 660-6590 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sun, 23 Jul 2000 00:02:15 +0900 > From: "Daniel C. Sobral" <dcs@newsguy.com> > Subject: Re: sysutils/memtest and FreeBSD > > Mario Sergio Fujikawa Ferreira wrote: > > > > Backtracing showed that the problem was due > > to the malloc function inside the get_mem function. > > get_mem() is used to find out the largest possible memory segment. > > It incrementaly reduces the segment passed to malloc to alloc. > > It is the malloc function allright. It core dumps on the > > 1st pass on get_mem(), there is no time to do_reduce. Very weird. ;( > > Because FreeBSD overcommits, malloc() will only fail in case of > artificial limits being reached (like those of login.conf). If FreeBSD > suddenly finds itself in a position of not being able to meet the > previous commitments wrt to memory allocation, it will kill the > application with the largest memory allocations. > > I'll bet you the fifth season of Babylon 5 this is what's happening. :-) > > Try limiting the maximum memory allocation to the total physical RAM. > > - -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > capo@white.bunnies.bsdconspiracy.net > > Satan was once an angel, Gates started by writing a BASIC interpreter. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sun, 23 Jul 2000 00:04:41 +0900 > From: "Daniel C. Sobral" <dcs@newsguy.com> > Subject: Re: /etc/defaults/make.conf:LEAPSECONDS= true? > > Mario Sergio Fujikawa Ferreira wrote: > > > > I was wondering if this should go inside > > /etc/defaults/make.conf. > > Submit a PR. > > > --- /usr/src/etc/defaults/make.conf Sun Jul 16 05:30:30 2000 > > +++ /tmp/make.conf Fri Jul 21 18:42:35 2000 > > @@ -41,6 +41,9 @@ > > # To build perl with thread support > > #PERL_THREADED= true > > # > > +# Compile zoneinfo with correct leap second handling > > +#LEAPSECONDS= true > > +# > > # To avoid building various parts of the base system: > > #NO_CVS= true # do not build CVS > > #NO_BIND= true # do not build BIND > > > > If it does not, where in the handbook should > > I drop a note about it, besides FAQ (of course). > > > > Regards, > > Mario Ferreira > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > - -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > capo@white.bunnies.bsdconspiracy.net > > Satan was once an angel, Gates started by writing a BASIC interpreter. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 22 Jul 2000 10:39:08 -0700 (PDT) > From: Matt Dillon <dillon@earth.backplane.com> > Subject: Re: clearing pages in the idle loop > > :> Since the only effect of a cache miss is less efficient use of > :> the cpu, and since the page zeroing only occurs when the cpu is idle, > :> I would not expect to see much improvement from attempts to refine > :> the page-zeroing operation (beyond the simple hysteresis that FreeBSD > :> uses now and perhaps being able to bypass the cache). > : > :The reason why I'm interested in Cort's results is that I'd like to extend > :processing in the idle loop to other things (see my other mail). Cort > :measured a performance decrease of foreground processing, due to polluted > :caches after idle-time processing. We're discussing if disabling caches > :during the idle loop may prevent that. > > I think what you are observing may not be cache-related at all, but may > simply be the fact that zeroing a page takes a minimum amount of time > during which another task will not be scheduled, verses that other task > being scheduled instantly if all the idle loop were doing was checking > for new tasks to run. > > :> The real benefit occurs on a medium-to-heavily loaded machine which is > :> NOT cpu bound. Since nearly all page allocations require zero'd pages, > :> having a pool of pre-zero'd pages significantly reduces allocation > :> latency at just the time the process doing the allocation can best > :> benefit from it. In a cpu-bound system, the idle loop does not run > :> as often (or at all) and no pre-zeroing occurs anyway. > : > :I agree. However, on a medium-to-heavily loaded CPU, you'd probably see the > :largest decrease of foreground performance, as the idle times are short and > :bursty, and so your caches may get polluted more frequently. (Assuming > :cache pollution is in fact a problem; Allan seems to not think so.) > : > :If Allan still has his patches, I'll run some experiments, so we have some > :numbers to talk about. Maybe it doesn't matter. > > Another alternative is to have an idle process rather then try to do > things in the idle loop. This has the advantage of being instantly > interruptable if a 'real' process becomes runnable, but the disadvantage > of having to do a context switch (albeit a relatively cheap one). > > The FreeBSD page zeroing code in the idle loop typically does not run > all that often with an interactive load because interactive loads tend > not to allocate memory at a high rate, so the hysteresis points do not > get hit as often. Hmm. Maybe there's a bug in the hysteresis > calculation, I'll check it out. > > -Matt > > :> In regards to just zeroing the pieces of a page that need zeroing - this > :> is NOT an optimization designed for the idle-loop page-zeroing code. > : > :I made a mistake tracing through the code. Sorry. > : > :But it may be interesting to speculate if this would speed things up. Would > :probably require MMU support though. > : > :Lars > :-- > :Lars Eggert <larse@isi.edu> Information Sciences Institute > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 22 Jul 2000 18:13:30 -0300 > From: "Mario Sergio Fujikawa Ferreira" <lioux@uol.com.br> > Subject: Re: sysutils/memtest and FreeBSD > > Daniel, > > On Sun, Jul 23, 2000 at 12:01:53AM +0900, Daniel C. Sobral wrote: > > Mario Sergio Fujikawa Ferreira wrote: > > > > > > Backtracing showed that the problem was due > > > to the malloc function inside the get_mem function. > > > get_mem() is used to find out the largest possible memory segment. > > > It incrementaly reduces the segment passed to malloc to alloc. > > > It is the malloc function allright. It core dumps on the > > > 1st pass on get_mem(), there is no time to do_reduce. Very weird. ;( > > > > Because FreeBSD overcommits, malloc() will only fail in case of > > artificial limits being reached (like those of login.conf). If FreeBSD > > suddenly finds itself in a position of not being able to meet the > > previous commitments wrt to memory allocation, it will kill the > > application with the largest memory allocations. > > > > I'll bet you the fifth season of Babylon 5 this is what's happening. :-) > > Are you willing to bet the 3rd and 4th seasons as well? > The 4th season rocks. ;-) > > > Try limiting the maximum memory allocation to the total physical RAM. > > The code sets limits appropriatily with RLIMIT_MEMLOCK and > RLIMIT_RSS with setrlimit(). > Furthermore, I am not using any limits for the user testing > the program (a can do it all user :). > Besides, a failing malloc should return NULL, shouldn't > it? I would have expected core if I had malloc_options="X" which > I do not (in fact, I have no malloc_options). > > Regards, > Mario Ferreira > > ps: Perhaps you could check the code, it is only 11K long. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sun, 23 Jul 2000 03:39:07 -0400 > From: "David E. Cross" <crossd@cs.rpi.edu> > Subject: 4.1-RC + SBLive + ECC = NMI > > I upgraded to 4.1-RC1 today; attempted to fire up esound and my system hung. > > I rebooted into X, fired up esound from text mode and system hung again > with a message that an NMI was caught. > > I remember that the SBLive has some issues with ECC systems, resulting in > some NMIs being thrown. It would appear that some of the recent fixes in > emu10k1.c v1.6.2.1 tickle this behavior. I am going to try to back-out to > 1.6 and see if this resolves the issue. Has anyone else experienced this? > Can I whap creative for producing such great hardware? :) > > - -- > David Cross | email: crossd@cs.rpi.edu > Lab Director | Rm: 308 Lally Hall > Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > Department of Computer Science | Fax: 518.276.4033 > I speak only for myself. | WinNT:Linux::Linux:FreeBSD > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sun, 23 Jul 2000 04:42:13 -0400 > From: "David E. Cross" <crossd@cs.rpi.edu> > Subject: Re: 4.1-RC + SBLive + ECC = NMI > > Hmm... backing out to emu10k1.c version 1.6 did not fix my problem. Does > anyone else have a SBLive! in an ECC machine that is throwing an NMI > whenever you try to use xmms or esd? If not, I will try to binary search > the dates to see if I can find when the change that tickeled the NMI bug on > the SBLive! was introduced. > > - -- > David Cross | email: crossd@cs.rpi.edu > Lab Director | Rm: 308 Lally Hall > Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > Department of Computer Science | Fax: 518.276.4033 > I speak only for myself. | WinNT:Linux::Linux:FreeBSD > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sun, 23 Jul 2000 13:06:54 +0400 (MSD) > From: Vsevolod Semenov <s@gw2.mtelecom.ru> > Subject: 4.0-RELEASE/tail/st_rdev > > I used "tail -F /var/log/local3" in my little shell script > to scan log for some string. > When i change release from 3.X to 4.0 > tail sometimes (may be once in a day or hours) > rescan log from begining and alarm me about problem > which has being occurred hours before. > > It was coz " sb2.st_rdev != sbp->st_rdev" > in /usr/src/usr.bin/tail/forward.c. > I've commented this out and became happy. > > > Q: Wtf is st_rdev in regular files in FreeBSD 4.0-RELEASE? > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sun, 23 Jul 2000 16:21:48 +0200 > From: Thomas Klausner <wiz@netbsd.org> > Subject: Re: minherit(2) API > > Mutt made be believe that Jason R Thorpe wrote: > > DONATE_COPY is not implemented in UVM. I'm not sure it was ever > > implemented anywhere. "Copy and delete" is really "move", right? > > Anyway, it's not clear those semantics are really useful at all. > > Okay, so let's skip that one. > > Any other comments? > > I think I can change it in NetBSD -- anyone willing to do the > necessary changes in FreeBSD and OpenBSD? > > Bye, > Thomas > > - -- > Thomas Klausner - wiz@danbala.tuwien.ac.at > I wanted to emulate some of my heroes, but I didn't know their > op-codes. --dowe > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > End of freebsd-hackers-digest V4 #901 > ************************************* > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?397B18A8.5713.3D69341>