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 <[EMAIL PROTECTED]>
> 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
> [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sat, 22 Jul 2000 16:01:59 +0200
> From: Poul-Henning Kamp <[EMAIL PROTECTED]>
> Subject: Re: Multiple ro mounts of vinum volume
>
> In message <[EMAIL PROTECTED]>, 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
> [EMAIL PROTECTED] | 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sat, 22 Jul 2000 10:22:08 -0400 (EDT)
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> Department of Computer Science Phone: (919) 660-6590
>
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sun, 23 Jul 2000 00:02:15 +0900
> From: "Daniel C. Sobral" <[EMAIL PROTECTED]>
> 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)
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Satan was once an angel, Gates started by writing a BASIC interpreter.
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sun, 23 Jul 2000 00:04:41 +0900
> From: "Daniel C. Sobral" <[EMAIL PROTECTED]>
> 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 [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
>
> - --
> Daniel C. Sobral (8-DCS)
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Satan was once an angel, Gates started by writing a BASIC interpreter.
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sat, 22 Jul 2000 10:39:08 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> Information Sciences Institute
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sat, 22 Jul 2000 18:13:30 -0300
> From: "Mario Sergio Fujikawa Ferreira" <[EMAIL PROTECTED]>
> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sun, 23 Jul 2000 03:39:07 -0400
> From: "David E. Cross" <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sun, 23 Jul 2000 04:42:13 -0400
> From: "David E. Cross" <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sun, 23 Jul 2000 13:06:54 +0400 (MSD)
> From: Vsevolod Semenov <[EMAIL PROTECTED]>
> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> Date: Sun, 23 Jul 2000 16:21:48 +0200
> From: Thomas Klausner <[EMAIL PROTECTED]>
> 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 - [EMAIL PROTECTED]
> I wanted to emulate some of my heroes, but I didn't know their
> op-codes. --dowe
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
> End of freebsd-hackers-digest V4 #901
> *************************************
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message