4.3-RC3/SMP
hi, at the begining of the 4.3 beta->rc->... i was having problems when doing a make -j4 buildworld, now with the latest, it's doing ok, but i think there is a slowdown: plain make: 1607.475u 674.053s 46:42.23 81.4% 1266+1445k 28160+305923io 1470pf+0w 1556.391u 575.160s 46:28.44 76.4% 1294+1445k 26065+173066io 1468pf+0w make -j4: 1602.193u 666.496s 45:52.42 82.4% 1268+1441k 8614+305942io 659pf+0w comments? danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lockf in apache
Alfred Perlstein wrote: > > We haven't applied wakeup_one() to select() yet? (I think I've argued > > about this before.) > > > > Someone get cracking! :) > > I'm not sure it's possible without redesigning the way select works. > Perhaps its not possible, as I'm not very familiar with the way kqueue works, but would it be possible to rewrite select() to use the kqueue() mechanism underneath, and thus avoid this situation? Or am I missing something? -- farooq <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Mon, 16 Apr 2001 04:02:34 -0700,
Alfred Perlstein <[EMAIL PROTECTED]> said:
Alfred> I'm also wondering why you can't track the number of
Alfred> nodes that ought to be cleaned, well, you do, but it doesn't
Alfred> look like it's used:
Alfred> + numcachehv--;
Alfred> + numcachehv++;
Alfred> then later:
Alfred> + if (vnodeallocs % vnoderecycleperiod == 0 &&
Alfred> + freevnodes < vnoderecycleminfreevn &&
Alfred> + vnoderecyclemintotalvn < numvnodes) {
Alfred> shouldn't this be related to numcachehv somehow?
One reason is that the number of directory vnodes attempted to reclaim
should be greater than vnoderecycleperiod, the period of reclaim in
getnewvnodes() calls. Otherwise, all of the vnodes reclaimed in the
last attempt might be eaten up by the next attempt.
This fact calls for an constraint of vnoderecyclenumber >=
vnoderecycleperiod, but it is not checked yet.
The other one is that not all of the directory vnodes in namecache
can be reclaimed because some of them may be held as the working
directory of a process. Since a directory vnode in namecache can
become or no longer be a working directory without entering or purging
namecache, it is rather hard to track the number of the reclaimable
directory vnodes in namecache by simple watching cache_enter() and
cache_purge().
While the number of reclaimable directory vnodes can be counted by
traversing the whole namecache entries, we again have to traverse
the namecache entries in order to actually reclaim vnodes, so this
method is not an option to predetermine the number of directory vnodes
attempted to reclaim.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
Date: Tue, 10 Apr 2001 22:14:28 -0700 From: Julian Elischer <[EMAIL PROTECTED]> To: Rik van Riel <[EMAIL PROTECTED]> CC: Matt Dillon <[EMAIL PROTECTED]>, David Xu <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: vm balance Rik van Riel wrote: > > I'm curious about the other things though ... FreeBSD still seems > to have the early 90's abstraction layer from Mach and the vnode > cache doesn't seem to grow and shrink dynamically (which can be a > big win for systems with lots of metadata activity). > > So while it's true that FreeBSD's VM balancing seems to be the > best one out there, I'm not quite sure about the rest of the VM... > Many years ago Kirk was talking about merging the vm objects and the vnodes.. (they tend to come in pairs anyhow) I still think it might be an idea worth investigating further. kirk? -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v I am still of the opinion that merging VM objects and vnodes would be a good idea. Although it would touch a huge number of lines of code, when the dust settled, it would simplify some nasty bits of the system. This merger is really independent of making the number of vnodes dynamic. Under the old name cache implementation, decreasing the number of vnodes was slow and hard. With the current name cache implementation, decreasing the number of vnodes would be easy. I concur that adding a dynamically sized vnode cache would help performance on some workloads. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Shoutcast, high cpu, threads
Hi, I'm running shoutcast on a 4.2R machine, and I'm finding that the shoutcast server, when idle climbs up to around 90% cpu usage. Included is a bit of back-and-forth with a shoutcast support person. I'm not too clear on what he's talking about, is there any information I can pass on to him to help debug this? While I will take his suggestion on increasing the sleep time, I don't want to push it too far or I may end up with a "stuttering" server. Thanks, Charles -- Forwarded message -- Date: Mon, 16 Apr 2001 10:27:33 -0700 From: Tom Pepper <[EMAIL PROTECTED]> To: Charles Sprickman <[EMAIL PROTECTED]> Subject: Re: high cpu usage keep going up. your machine is fast enough that values as high as 10,000 may show improvement. you're seeing this problem because freebsd is the only o/s i know of that ignores sleep values with very small microsecond values. it seems to be aggravated by the amount of different pc hardware available, which is why the config option for sleep is definable. -t At 07:45 PM 4/14/2001 -0400, you wrote: >How far can I go? The conf file says the recommended max is 1,024 and >that setting it too high might cause skipping... > >Here's the result with 0 listeners and the sleep timer set to 999: > > PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND >25292 scserv55 0 46860K 46340K RUN 1:09 93.58% 91.16% sc_serv > >The cpu usage goes down as more people connect. Odd. > >In the forums, there is a post about this, and the guy fixed it by using >the freebsd 3.x version. Perhaps I'll try that? Or even the Linux >version under emulation? > >It just seems odd that it should chew up all that processor (this is an >otherwise idle PIII-800) doing nothing... > >Thanks, > >Charles > >| Charles Sprickman | Internet Channel >| INCH System Administration Team| (212)243-5200 >| [EMAIL PROTECTED] | [EMAIL PROTECTED] > >On Sat, 14 Apr 2001, Tom Pepper wrote: > > > try increasing the sleep= value in the .conf file and let me know at > > what point it seems to work for you. > > > > -t > > > > On Friday, April 13, 2001, at 11:31 PM, Charles Sprickman wrote: > > > > > Hi, > > > > > > We're checking this out on FreeBSD 4.2, and it seems to work OK, even as > > > it chews up CPU. > > > > > > Currently, the server is idle, web interface still responding, etc: > > > > > > last pid: 19214; load averages: 1.04, 1.05, 1.01 up 50+12:28:15 > > > 02:27:23 > > > 25 processes: 2 running, 23 sleeping > > > CPU states: 41.2% user, 0.0% nice, 57.2% system, 0.0% interrupt, 1.6% > > > idle > > > Mem: 411M Active, 151M Inact, 90M Wired, 44K Cache, 112M Buf, 353M Free > > > Swap: 1024M Total, 1024M Free > > > > > > PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND > > > 16822 scserv53 0 6660K 6108K RUN463:43 96.19% 96.19% sc_serv > > > 43230 mysql 2 0 415M 400M poll 581:21 0.00% 0.00% mysqld > > > > > > Any idea why the high cpu usage? We've been playing with RealServer and > > > outsourced WMA crap, and now we're trying shoutcast. Other than this, > > > it > > > looks good. > > > > > > Let me know if there's any information you'd like. > > > > > > Thanks, > > > > > > Charles > > > > > > | Charles Sprickman | Internet Channel > > > | INCH System Administration Team| (212)243-5200 > > > | [EMAIL PROTECTED] | [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ypserv: a resolution (i think)
I'm open to the idea of fixing it, but I wouldn't mind just another day or two of testing first, hopefully with other folks involved. I didn't see a diff attached? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: User-defined bit in sysctl flags ?
* Darren Reed <[EMAIL PROTECTED]> [010416 13:37] wrote: > > What do people think about having a range of bits in oid_kind that are > not used by FreeBSD but are only to be used by ``private'' sysctl handlers? > > e.g. > > #define CTLFLAG_PRIVATE 0x0000 > > Do I need elaborate any further ? I think a half-paragraph explaining what this does would help. :) I'm assuming this allows someone to have thier own private numbered mib in the sysctl tree, my question is why are you using hardcoded numbers rather than names? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ypserv: a resolution (i think)
After some more intensive debugging, and a leap of faith, I _think_ I have the problem licked, but I would appreciate some more brains to examine the logic. The original cause of ypserv's problems was the sharing of DBPs between the parent and child. The resolution to this was to close all of them, in the child. This appears to be where the problem lies, it was assumed to be safe to call the dbclose in the child... apparently dbclose does some stuff that is still dangerous. So, my solution is to move the close routine _before_ the fork (so far *crossed fingers* this is working). However, since yp_all is called fairly frequently, this is bad(TM) for the parent. My second solution was to have the child call yp_init_dbs() instead of yp_flush_all() (the former would just nuke the references to the FDs, but actually keep them open). This didn't work. Can anyone provide any clues as to why? Does the DB library keep its own cache, and unless they are "really" closed it will just loop back to the open ones anyway? The current solution is suboptimal since for many cases it removes the DBCACHE entirely, but I don't know what other solution exists. I know some others who use ypserv heavily have run into these problems, if you need the patch, I can provide it if you are willing to give it a test ;) JKH: I think this _really_ needs to get into 4.3-RELEASE, this has been a vexing bug for over a year. The current solution may be sub-optimal, but it is more optimal than: pid 75351 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75364 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75365 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75370 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75377 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75379 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75215 (ypserv), uid 0: exited on signal 11 (core dumped) ;) -- 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
Re: Idea about modules build
It would also be nice to be able to update third-party modules (like those in ports, x11, etc...) after a kernel recompile. Perhaps some way of setting these up into /usr/local? Peter Pentchev had the audacity to say: > > On Sat, Apr 14, 2001 at 07:51:31PM +0400, Vladimir B. Grebenschikov wrote: > > > > I have idea about modules build/install process: > > > > May be it need to create some makefile variable like KERNEL_MODULES, > > that can be defined in /etc/make.conf to limit list of modules > > to build/install, it is not very good idea to spend a lot of > > CPU time building modules, that never be used ? > > This was recently discussed on -arch, and was brought into -current > by Warner Losch <[EMAIL PROTECTED]> in rev. 1.172 of src/sys/modules/Makefile > from 2001/04/02 08:52:05; if there is a MODULES_OVERRIDE variable (defined > either in /etc/make.conf or on the 'make' command line), it overrides > the list of modules to build. This variable can - and probably should ;) - > contain second-level module names, too - e.g. sound/pcm or syscons/daemon. > > G'luck, > Peter > > -- > This sentence would be seven words long if it were six words shorter. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > PGP signature
still more ypserv woes
Ok... I am coming to the conclusion that there is some sort of kernel issue that is causing this problem. Here is what I have done and discovered to date (this is all with 4.3-RC2 FWIW): At some point the 'qhead' CIRCLEQ structure in yp_dblookup.c gets corrupted. This is declared as a static, and no handles are passed back out of the function, so aside from data-segment smashing, all accesses to that structure _must_ happen within yp_dblookup.c. To date, _almost_ every single segfault has been in the for loop of yp_testflags (this is a bit odd in and of itself given that the CIRCLEQ is being mangled) ( I do not recall the exact situation for the one not in yp_testflags. ), so I wrote a function called 'queue_verify()' whose only lob is to travel once down the CIRCLEQ, assert the number of entries in the CIRCLEQ is the same as numdbs and exit. I placed this function after every Berkeley DB function call and other random points in the function calls in "yp_dblookup.c". Right now I am only seeing seg-faults in the queue_verify() that I placed before the for loop in yp_testflags *very* strange, one would think with the number I have placed everywhere that it would get tripped up somewhere else too). I also notice that it always dies very shortly after it fork()s a child to handle a YP_ALL request (one of the things the child does is the delete its copy of the CIRCLEQ). Is it possible that a copy-on-write is somehow getting mangled and causing this? FWIW: this system is a single CPU PentiumPro acting as a firewall/gateway with 1 FXP, 2 dc, and 2 xl interfaces (the fxp and one each of the dc and xl are active). Any ideas? Any clue where to look next, I am running out ideas here. -- 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
User-defined bit in sysctl flags ?
What do people think about having a range of bits in oid_kind that are not used by FreeBSD but are only to be used by ``private'' sysctl handlers? e.g. #define CTLFLAG_PRIVATE 0x0000 Do I need elaborate any further ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Seigo Tanim ura writes: >Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff > >has been updated and now ready to commit. Ok, I ran a "cvs update ; make buildworld" here with and without your patch. without: 2049.846u 1077.358s 41:29.65 125.6% 594+714k 121161+5608io 7725pf+331w with: 2053.464u 1075.493s 41:29.50 125.6% 595+715k 123125+5682io 8897pf+446w Difference: + .17% -.18% ~0% 0% +.17% +.14% +1.6% +1.3% +15% +35% I think that means we're inside epsilon for the normal case, so I'll commit your patch later tonight. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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
Re: freebsd in dos extended ?
I have exceded my partitions limit & cannot delete my extended windoze is on it .. it seems that i am out of luck no problem i think its time to buy a new harddrive :-) i wish they didnt have this limit of 4 primary partition on a disk ... :-( - Original Message - From: "Mike Makonnen" <[EMAIL PROTECTED]> To: "faisal" <[EMAIL PROTECTED]>; "Andrew Hesford" <[EMAIL PROTECTED]>; "Will Mitayai Keeso Rowe" <[EMAIL PROTECTED]> Cc: "FreeBSD" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, April 16, 2001 12:51 AM Subject: Re: freebsd in dos extended ? > > > Why do you want to install it on a DOS extended partition? > Just remove that extended patition and install FreeBSD in the unused > portion > of the disk. Install the FreeBSD boot manager so you can boot into > whichever OS you want to. > > Mike. > > > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting article.
Bakul Shah wrote: > > > > Though, a lack of good Unicode support on FreeBSD seems like > > > a legitimate enough reason for the move. > > > > Yes, it would, if it were true, see /usr/ports/devel/libunicode. > > One port does not make good support. For that FreeBDS has to > have native unicode support. Why? All they're interested in is having unicode in their web-based app. > > In order to determine if they really made any savings or not -- I > > notice that they've increased the number of servers at Hotmail from > > 3,400 to 5,000 - you'd also have to determine how much they could have > > improved the performance by merely writing their code as an Apache > > module. > > If as they claim they doubled the performance, they saved a > few mil in not having to use 10,000 servers. My point was > they didn't save *as much money as* they could've, had they > used various performance increasing tricks we are well aware > of. We're definitely in agreement on that. They did not start this project to save money, though they claim that as a motivation. It would have (most likely) been far less expensive to make a few performance enhancements to Apache itself, or to the interface they use for their application code. Of course, that would not have been a testimonial for Win2K or IIS. > > So, was that 18 month development project really necessary from a > > technical standpoint, or only justified as a marketing cost? Nobody > > outside Microsoft management will ever really know. > > Suspect the most likely cause of conversion can be summed up > in the phrase `eating your own dogfood'. Which is fine, but it's disingenous to declare it a 'cost-saving measure' when it was obviously very expensive. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Is it ok to compile a device driver as a module though no load_function is declared in DRIVER_MODULE()?
Hi, i've got a little question about device drivers for FreeBSD. I'm testing my device driver by compiling it as a module and kldloading it. But as I don't want to use it as a module in the future I declared DRIVER_MODULE(..) as follows: DRIVER_MODULE( ir, isa, ir_isa_driver, ir_devclass, 0, 0); As I read on deamonnews that one has to declare a load_function to use a driver as a KLD I'm not sure if the above DRIVER_MODULE() is valid for testing. I can see that my identify and probe functions are called but I'm not sure if this can cause troubles if I don't declare a load_function but let the system get the device by identifying and probing it. Can it? If yes, how can I get "dev" to get my softc structure with device_get_softc(dev) within a load function. Sorry for my bad english. Please answer directly to me as I'm not on the list. Greetings, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Seigo Tanim ura writes: >Poul-Henning> I'm a bit worried about the amount of work done in the >Poul-Henning> cache_purgeleafdirs(), considering how often it is called, > >Poul-Henning> Do you have measured the performance impact of this to be an >Poul-Henning> insignificant overhead ? > >No precise results right now, mainly because I cannot find a benchmark >to measure the performance of name lookup going down to a deep >directory depth. Have you done any "trivial" checks, like timing "make world" and such ? >It has been confirmed, though, that the hit ratio of name lookup is >around 96-98% for a box serving cvsup both with and without my patch >(observed by systat(1)). Here are the details of the name lookup on >that box: Ohh, sure, I don't expect this to have a big impact on the hit rate, If I thought it would have I would have protested :-) >For a more precise investigation, we have to measure the actial time >taken for a lookup operation, in which case I may have to write a >benchmark for it and test in single-user mode. I would be satisfied with a "sanity-check", for instance running a "cvs co src ; cd src ; make buildworld ; cd release ; make release" with and without, just to see that it doesn't have a significant negative impact. >It is interesting that the hit ratio of directory lookup is up to only >1% at most, even without my patch. Why is it like that? Uhm, which cache is this ? The one reported in "vmstat -vm" ? That is entirely different from the vfs-namecache, I think it is a per process one-slot directory cache. I have never studied it's performance, but I belive a good case was made for it in the 4.[34] BSD books. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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
Re: vm balance
On Mon, 16 Apr 2001 12:36:03 +0200, Poul-Henning Kamp <[EMAIL PROTECTED]> said: Poul-Henning> In message <[EMAIL PROTECTED]>, Seigo Tanim Poul-Henning> ura writes: >> Those pieces of work were done in the last weekend, and the patch at >> Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff >> >> has been updated and now ready to commit. Poul-Henning> I'm a bit worried about the amount of work done in the Poul-Henning> cache_purgeleafdirs(), considering how often it is called, Poul-Henning> Do you have measured the performance impact of this to be an Poul-Henning> insignificant overhead ? No precise results right now, mainly because I cannot find a benchmark to measure the performance of name lookup going down to a deep directory depth. It has been confirmed, though, that the hit ratio of name lookup is around 96-98% for a box serving cvsup both with and without my patch (observed by systat(1)). Here are the details of the name lookup on that box: Frequency: Around 25,000-35,000 lookups/sec at most, 8,000-10,000 generally. Name vs Directory: 98% or more of the lookups are for names, the rest of them are for directories (up to 1.5% of the whole lookup at most). Hit ratio: 96-98% for names and up to 1% at most for directories (both with and without my patch) Considering that most of lookup operations are for names and its hit ratio is not observed to degrade, and assuming that the time consumed for lookup hit is always constant, the performance of lookup is not found to be deteriorated. For a more precise investigation, we have to measure the actial time taken for a lookup operation, in which case I may have to write a benchmark for it and test in single-user mode. It is interesting that the hit ratio of directory lookup is up to only 1% at most, even without my patch. Why is it like that? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
* Seigo Tanimura <[EMAIL PROTECTED]> [010416 03:25] wrote:
> On Fri, 13 Apr 2001 20:08:57 +0900,
> Seigo Tanimura said:
>
> Alfred> Are these changes planned for integration?
>
> Seigo> Yes, but not very soon as there are a few kinds of works that should
> Seigo> be done.
>
> Seigo> One is that a directory vnode may be held as the working directory of
> Seigo> a process, in which case we should not reclaim the directory vnode.
>
> Seigo> Another is to determine how often namecache should be traversed to
> Seigo> reclaim how many directory vnodes. At this moment, namecache is
> (snip)
>
> Those pieces of work were done in the last weekend, and the patch at
>
> Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff
>
> has been updated and now ready to commit.
There's actually a few style bugs in here:
pointers should be compared against NULL, not 0
using a bit more meaningful variable names would be nice:
+ struct nchashhead *ncpp;
+ struct namecache *ncp, *nnp, *ncpc, *nnpc;
I'm also wondering why you can't track the number of
nodes that ought to be cleaned, well, you do, but it doesn't
look like it's used:
+ numcachehv--;
+ numcachehv++;
then later:
+ if (vnodeallocs % vnoderecycleperiod == 0 &&
+ freevnodes < vnoderecycleminfreevn &&
+ vnoderecyclemintotalvn < numvnodes) {
shouldn't this be related to numcachehv somehow?
excuse me if i'm missing something obvious, i'm in desperate need
of sleep. :)
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Seigo Tanim ura writes: >Those pieces of work were done in the last weekend, and the patch at > >Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff > >has been updated and now ready to commit. I'm a bit worried about the amount of work done in the cache_purgeleafdirs(), considering how often it is called, Do you have measured the performance impact of this to be an insignificant overhead ? Once we have that figured out I will commit the patch for you... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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
Re: Idea about modules build
On Sat, Apr 14, 2001 at 07:51:31PM +0400, Vladimir B. Grebenschikov wrote: > > I have idea about modules build/install process: > > May be it need to create some makefile variable like KERNEL_MODULES, > that can be defined in /etc/make.conf to limit list of modules > to build/install, it is not very good idea to spend a lot of > CPU time building modules, that never be used ? This was recently discussed on -arch, and was brought into -current by Warner Losch <[EMAIL PROTECTED]> in rev. 1.172 of src/sys/modules/Makefile from 2001/04/02 08:52:05; if there is a MODULES_OVERRIDE variable (defined either in /etc/make.conf or on the 'make' command line), it overrides the list of modules to build. This variable can - and probably should ;) - contain second-level module names, too - e.g. sound/pcm or syscons/daemon. G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
* Seigo Tanimura <[EMAIL PROTECTED]> [010416 03:25] wrote: > On Fri, 13 Apr 2001 20:08:57 +0900, > Seigo Tanimura said: > > Alfred> Are these changes planned for integration? > > Seigo> Yes, but not very soon as there are a few kinds of works that should > Seigo> be done. > > Seigo> One is that a directory vnode may be held as the working directory of > Seigo> a process, in which case we should not reclaim the directory vnode. > > Seigo> Another is to determine how often namecache should be traversed to > Seigo> reclaim how many directory vnodes. At this moment, namecache is > (snip) > > Those pieces of work were done in the last weekend, and the patch at > > Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff > > has been updated and now ready to commit. Heh, go for it. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Fri, 13 Apr 2001 20:08:57 +0900, Seigo Tanimura said: Alfred> Are these changes planned for integration? Seigo> Yes, but not very soon as there are a few kinds of works that should Seigo> be done. Seigo> One is that a directory vnode may be held as the working directory of Seigo> a process, in which case we should not reclaim the directory vnode. Seigo> Another is to determine how often namecache should be traversed to Seigo> reclaim how many directory vnodes. At this moment, namecache is (snip) Those pieces of work were done in the last weekend, and the patch at Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff has been updated and now ready to commit. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sysctl question (again)
* Oscar-Ivan Lepe-Aldama <[EMAIL PROTECTED]> [010416 02:34] wrote:
> Hi!
> the technical question follows the next commentary. This is the second
> (third) time I post this question. I'm wondering why I haven't got any
> answers. Is it because this isn't the right forum? Is it because I
> haven't been clear enough? Is it because my bad english? Any clue on why
> the people in this forum can not give me any kind of answer for the
> following question will be aprreciated. Now, the technical question
> follows.
>
> Is there a maximum for the size of an object that sysctl can handle?
>
> I'm asking this because I have inserted in a 4.1.1 kernel an array
> defined as
>
>
> struct buf_entry {
> unsgined intid;
> u_int64_t tsc;
> u_int64_t pmec1;
> u_int64_t pmec2;
> } mybuffer[NUMENTRIES];
>
> SYSCTL_NODE(, CTL_NAVI, experiments, CTLFLAG_RW, 0,"Experiments");
> SYSCTL_OPAQUE(_experiments, OID_AUTO, buffer, CTLFLAG_RD, &mybuffer,
> sizeof(mybuffer), "", "");
>
>
> When NUMENTRIES equals 10 (100 thousand) everything works well; that
> is, I can read the content of the array using
>
> sysctl -b experiments.mybuffer > somefile.raw
>
> But when NUMENTRIES equals 100 (1 million) and I use the above
> command to read the content of the array, the system stops working
> properly; that is, all virtual terminals freezed so I can't sent any
> command to the system, although the kernel seams to be alive as it
> responds to ICMP echo packets.
>
> I do want to have a large array within the kernel's memory space as I'm
> measuring the performance of some kernel's routines using the Pentium's
> Performance Monitoring Event Counters, and the more performance data I
> could get in one experiment the best.
>
> By the way, the system under test has 64 MB of RAM and 20 GB of free
> space on disk.
>
> Any explanation on the possibility or the impossibility of having such
> large array within the kernel memory-space and having it exported
> through sysctlt will be verry much appreciated.
>
uh:
struct buf_entry {
4 unsgined intid;
8 u_int64_t tsc;
8 u_int64_t pmec1;
8 u_int64_t pmec2;
} mybuffer[NUMENTRIES];
28 * 1,000,000 = 28Megs
That's quite a bit of space to wire down in your kernel, especially for
a 64meg box. I would get more ram.
You can also read on how to enable a kernel debugger and get us a meaningful
traceback in order to possibly fix the problem.
-Alfred
> Thanks,
>
> --
>
> 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC
> 0 0 0 e-mail: [EMAIL PROTECTED]| Modul D6, despatx 116
> 0 0 0 phone: +34 93 401 7187| Jordi Girona, 1-3
> U P C fax:+34 93 401 7055| 08034 Barcelona - SPAIN
> WWW:http://www.ac.upc.es/homes/oscar/
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Sysctl question (again)
Hi!
the technical question follows the next commentary. This is the second
(third) time I post this question. I'm wondering why I haven't got any
answers. Is it because this isn't the right forum? Is it because I
haven't been clear enough? Is it because my bad english? Any clue on why
the people in this forum can not give me any kind of answer for the
following question will be aprreciated. Now, the technical question
follows.
Is there a maximum for the size of an object that sysctl can handle?
I'm asking this because I have inserted in a 4.1.1 kernel an array
defined as
struct buf_entry {
unsgined intid;
u_int64_t tsc;
u_int64_t pmec1;
u_int64_t pmec2;
} mybuffer[NUMENTRIES];
SYSCTL_NODE(, CTL_NAVI, experiments, CTLFLAG_RW, 0,"Experiments");
SYSCTL_OPAQUE(_experiments, OID_AUTO, buffer, CTLFLAG_RD, &mybuffer,
sizeof(mybuffer), "", "");
When NUMENTRIES equals 10 (100 thousand) everything works well; that
is, I can read the content of the array using
sysctl -b experiments.mybuffer > somefile.raw
But when NUMENTRIES equals 100 (1 million) and I use the above
command to read the content of the array, the system stops working
properly; that is, all virtual terminals freezed so I can't sent any
command to the system, although the kernel seams to be alive as it
responds to ICMP echo packets.
I do want to have a large array within the kernel's memory space as I'm
measuring the performance of some kernel's routines using the Pentium's
Performance Monitoring Event Counters, and the more performance data I
could get in one experiment the best.
By the way, the system under test has 64 MB of RAM and 20 GB of free
space on disk.
Any explanation on the possibility or the impossibility of having such
large array within the kernel memory-space and having it exported
through sysctlt will be verry much appreciated.
Thanks,
--
0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC
0 0 0 e-mail: [EMAIL PROTECTED]| Modul D6, despatx 116
0 0 0 phone: +34 93 401 7187| Jordi Girona, 1-3
U P C fax:+34 93 401 7055| 08034 Barcelona - SPAIN
WWW:http://www.ac.upc.es/homes/oscar/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd in dos extended ?
Why do you want to install it on a DOS extended partition? Just remove that extended patition and install FreeBSD in the unused portion of the disk. Install the FreeBSD boot manager so you can boot into whichever OS you want to. Mike. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
