Re: Allocate a page at interrupt time
Matt Dillon wrote: Yes, that is precisely the reason. In -current this all changes, though, since interrupts are now threads. *But*, that said, interrupts cannot really afford to hold mutexes that might end up blocking them for long periods of time so I would still recommend that interrupt code not attempt to allocate pages out of PQ_CACHE. I keep wondering about the sagicity of running interrupts in threads... it still seems like an incredibly bad idea to me. I guess my major problem with this is that by running in threads, it's made it nearly impossibly to avoid receiver livelock situations, using any of the classical techniques (e.g. Mogul's work, etc.). It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with the big giant lock and redirecting interrupts to the CPU in the kernel is better than that... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Symbol Question
Tabor Kelly wrote: Which source file(s) are the kernel symbols defined in? By symbols I mean the symbols that the nlist() man page refers to. Let's see... The nlist() function retrieves name list entries from the symbol table of an executable file (see a.out(5)). In the case of the kernel, that would be the kernel you booted, typically /kernel. Besides the source files, is there any other place that the symbols (their names and meaning) are documented? The section 9 man pages. Actually, you're lucky if they're documented in the source... -- 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
Re: Allocate a page at interrupt time
On Mon, Aug 06, 2001 at 11:27:56PM -0700, Terry Lambert wrote: I keep wondering about the sagicity of running interrupts in threads... it still seems like an incredibly bad idea to me. I guess my major problem with this is that by running in threads, it's made it nearly impossibly to avoid receiver livelock situations, using any of the classical techniques (e.g. Mogul's work, etc.). References to published works? It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual Can you point us at any concrete information that shows this? Specifically, without being Microsoft biased (as is most data published by Microsoft)? -- i.e. preferably third-party performance testing that attributes wiring down of interrupts to particular CPUs as _the_ performance advantage. wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with Obviously. the big giant lock and redirecting interrupts to the CPU in the kernel is better than that... -- Terry -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
* Bosko Milekic [EMAIL PROTECTED] [010807 02:16] wrote: On Mon, Aug 06, 2001 at 11:27:56PM -0700, Terry Lambert wrote: I keep wondering about the sagicity of running interrupts in threads... it still seems like an incredibly bad idea to me. I guess my major problem with this is that by running in threads, it's made it nearly impossibly to avoid receiver livelock situations, using any of the classical techniques (e.g. Mogul's work, etc.). References to published works? It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual Can you point us at any concrete information that shows this? Specifically, without being Microsoft biased (as is most data published by Microsoft)? -- i.e. preferably third-party performance testing that attributes wiring down of interrupts to particular CPUs as _the_ performance advantage. wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with Obviously. the big giant lock and redirecting interrupts to the CPU in the kernel is better than that... I really don't see what part of the current design specifically disallows one to both: 1) force interrupts to be taken on a particular cpu. 2) if that thread gets switched out, have it put on a per-cpu runqueue when it becomes runable preventing another cpu from snatching it up. I've already implemented #2, #1 requires touching hardware which isn't something I like doing. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: timing question
Jeff Behl wrote: please excuse and direct me to the right place if this isn't the appropriate place to post this sort of question we're looking into moving to freebsd (yea!), but found the following problem. It seems that the shortest amount of time the below code will sleep for is 20 seconds! any call to nanosleep for 5,10, etc miliseconds returns a 20 ms delay. are we doing something wrong? You appear to be measuring the quantum. You can decrease the quantum size via sysctl, or at compile time. Realize that your timing is tight enough that if you are running any other code, you can't expect that your process will get the quantum next, unless you use rtprio. Also note that your timer granularity might be someone less than you would expect: in other words it could be returning before, but since the sleep is woken up as the result of a timer interrupt firing, you may need to increase the rate your clock runs at (search for HZ in /sys/i386/conf/LINT) to make your timer interrupts faster, which will in turn increase your timeout resolution. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with the big giant lock and redirecting interrupts to the CPU in the kernel is better than that... Terry, this is *total* garbage. Just so you know, ok? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyXXXX_r()
Richard Seaman, Jr. wrote: On Sat, Aug 04, 2001 at 12:04:02AM -0600, Wes Peters wrote: Alfred Perlstein wrote: * Alexander Litvin [EMAIL PROTECTED] [010803 09:54] wrote: Are there any plans of making gethostbyname_r() and gethostbyaddr_r() available in FreeBSD? May be somebody already has them almost ready to be commited? Or are there any considered wrong way to go? The reason I'm asking is that I actually have a local patch implementing them here (only for DNS for now). Is it good idea to put some effort to finalaze it and submit a PR? Or I'd better not waist time on that? Please complete it, let me know when you submit the PR i'll try to get it integrated. I'll be happy to take a look at it too. I did a lot of the _r routines we have now, in some cases simply documenting ones that were there, but halted when I got to gethostbyX_r and the passwd and group variants, because they were too fugly to tackle at that time. I'll get back to the remainder someday, when I have the time, unless you beat me to it. There are some gethostby_r, getnetby_r, ... etc routines in the linuxthreads port (/usr/ports/devel/linuxthreads/files). These came from the original linuxthreads package, and have no copyright on them. I never researched the copyright status of them, but I don't think they are GPL, though you might want to do further research on their history if you use them. If they're just mutex-protected variants, I haven't bothered to create any of those. I guess they might be of use to somebody, but I very much wanted to create _r routines that were implemented properly, not just wrap the non-_r routines in a mutex, which is bass-ackwards. -- 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
Re: Allocate a page at interrupt time
Bosko Milekic wrote: I keep wondering about the sagicity of running interrupts in threads... it still seems like an incredibly bad idea to me. I guess my major problem with this is that by running in threads, it's made it nearly impossibly to avoid receiver livelock situations, using any of the classical techniques (e.g. Mogul's work, etc.). References to published works? Just do an NCSTRL search on receiver livelock; you will get over 90 papers... http://ncstrl.mit.edu/ See also the list of participating institutions: http://ncstrl.mit.edu/Dienst/UI/2.0/ListPublishers It won't be that hard to find... Mogul has only published 92 papers. 8-) It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual Can you point us at any concrete information that shows this? Specifically, without being Microsoft biased (as is most data published by Microsoft)? -- i.e. preferably third-party performance testing that attributes wiring down of interrupts to particular CPUs as _the_ performance advantage. FreeBSD was tested, along with Linux and NT, by Ziff Davis Labs, in Foster city, with the participation of Jordan Hubbard and Mike Smith. You can ask either of them for the results of the test; only the Linux and NT numbers were actually released. This was done to provide a non-biased baseline, in reaction to the Mindcraft benchmarks, where Linux showed so poorly. They ran quad ethernet cards, with quad CPUs; the NT drivers wired the cards down to seperate INT A/B/C/D interrupts, one per CPU. wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with Obviously. I mention it because this is the direction FreeBSD appears to be moving in. Right now, Intel is shipping with seperate PCI busses; there is one motherboard from their serverworks division that has 16 seperate PCI busses -- which means that you can do simultaneous gigabit card DMA to and from memory, without running into bus contention, so long as the memory is logically seperate. NT can use this hardware to its full potential; FreeBSD as it exists, can not, and FreeBSD as it appears to be heading today (interrupt threads, etc.) seems to be in the same boat as Linux, et. al.. PCI-X will only make things worse (8.4 gigabit, burst rate). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
Mike Smith wrote: It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with the big giant lock and redirecting interrupts to the CPU in the kernel is better than that... Terry, this is *total* garbage. Just so you know, ok? What this, exactly? That virtual wire mode is actually a bad idea for some applications -- specifically, high speed networking with multiple gigabit ethernet cards? That Microsoft demonstrated that wiring down interrupts to a particular CPU was a good idea, and kicked both Linux' and FreeBSD's butt in the test at ZD Labs? That taking interrupts on a single directed CPU is better than taking an IPI on all your CPUs, and then sorting out who's going to handle the interrupt? Can you name one SMP OS implementation that uses an interrupt threads approach that doesn't hit a scaling wall at 4 (or fewer) CPUs, due to heavier weight thread context switch overhead? Can you tell me how, in the context of having an interrupt thread doing scheduled processing, how you could avoid an interrupt overhead livelock, where the thread doesn't get opportunity to run because you're too busy taking interrupts to be able to get any work done? FWIW, I would be happy to cite sources to you, off the general list. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[PATCH] pam_wheel fix
Hello, can anyone please commit this fix to pam_wheel authentication module. It fixed two problem I mentioned in my previous mail (currently for any non-root user PAM_IGNORE is returned, and in case of auth_as_self and debug options used together it logs strange things instead of username). The patch must be applied in src/lib/libpam/modules/pam_wheel/ Regards, Eugene --- pam_wheel_old.c Tue Aug 7 17:46:20 2001 +++ pam_wheel.c Tue Aug 7 17:48:04 2001 @@ -84,11 +84,14 @@ PAM_RETURN(retval); pwd = getpwnam(user); } + + if (!pwd) + PAM_RETURN(PAM_IGNORE); - PAM_LOG(Got user: %s, user); + PAM_LOG(Got user: %s, pwd-pw_name); /* Ignore if already uid 0 */ - if (pwd-pw_uid) + if (!pwd-pw_uid) PAM_RETURN(PAM_IGNORE); PAM_LOG(Not superuser);
Ypbind malfunction on 4.x
Hi: If I'm posting to the wrong list, please let me know. There is a long-running problem in FreeBSD's yp/ypbind that is evidenced by: Aug 4 02:01:43 tuva ypbind[160]: NIS server [192.32.150.15] for domain engeast not responding Aug 4 02:02:14 tuva last message repeated 30 times Aug 4 02:04:15 tuva last message repeated 121 times (And there would be other messages about throttling icmp messages, except I've applied a patch to ypbind.c that at least throttles things down to 1 message per second. This patch was posted to questions.) ... and it never rebinds to any other server. The only way I've found to fix the problem is to reboot. I am experiencing this in 4.3 Release, and I've had it in 4.2 and earlier. This problem has seen a little discussion in questions. But I've never seen anything in any of the lists about a solution to the core problem. Maybe I've missed this? Anyone working on this? It is a pretty serious problem (since you basically can't do anything once it happens in typical NIS/Amd installations). I'd appreciate, at least, knowing if there is a non-reboot work-around. Thanks! -- Robert Withrow -- (+1 978 288 8256, ESN 248) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: dmesg behaviour
Dear, On the supermicro systems, we may see the information from the last 3 boots! I see the lines: syncing disks... done Rebooting... and then we go right into the next boot. At present, one of the machines shows all the detail from 2.75 reboots. How and why is it doing this, and how do I make it stop? FWIW, FreeBSD/alpha also exhibits this behaviour. Perhaps it's better to adapt your tools to cope to improve their portability between FreeBSD-supported architectures? Kees Jan = You can't have everything. Where would you put it? [Steven Wright] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ypbind malfunction on 4.x
I think that there has been quite a lot of work on ypbind recently. Try updating to 4.3-STABLE (actually 4.4-PRERELEASE now), there were several patches in that area in the past week or two. Or alternatively, wait for 4.4-RELEASE about the end of August. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? On Tue, Aug 07, 2001 at 11:07:48AM -0400, Robert Withrow wrote: Hi: If I'm posting to the wrong list, please let me know. There is a long-running problem in FreeBSD's yp/ypbind that is evidenced by: Aug 4 02:01:43 tuva ypbind[160]: NIS server [192.32.150.15] for domain engeast not responding Aug 4 02:02:14 tuva last message repeated 30 times Aug 4 02:04:15 tuva last message repeated 121 times (And there would be other messages about throttling icmp messages, except I've applied a patch to ypbind.c that at least throttles things down to 1 message per second. This patch was posted to questions.) ... and it never rebinds to any other server. The only way I've found to fix the problem is to reboot. I am experiencing this in 4.3 Release, and I've had it in 4.2 and earlier. This problem has seen a little discussion in questions. But I've never seen anything in any of the lists about a solution to the core problem. Maybe I've missed this? Anyone working on this? It is a pretty serious problem (since you basically can't do anything once it happens in typical NIS/Amd installations). I'd appreciate, at least, knowing if there is a non-reboot work-around. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: timing question
From: Alfred Perlstein [EMAIL PROTECTED] To: Jeff Behl [EMAIL PROTECTED] CC: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Re: timing question Date: Mon, 6 Aug 2001 14:49:55 -0500 * Jeff Behl [EMAIL PROTECTED] [010806 12:48] wrote: please excuse and direct me to the right place if this isn't the appropriate place to post this sort of question we're looking into moving to freebsd (yea!), but found the following problem. It seems that the shortest amount of time the below code will sleep for is 20 seconds! any call to nanosleep for 5,10, etc miliseconds returns a 20 ms delay. are we doing something wrong? You may have to increase the kernel value for HZ so that you get more fine grained clock interrupts. I didn't look at the code but if increasing the value of 'hz' will result in more clock-interrupts/sec thus more overhead, wouldn't it be better to auto-adjust the clock-interrupt rate somewhere in the OS to clock-interrupt at big strides in the beginning but at finer-grained interval as the actual timeout event approaches? Weiguang _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Welcome to the freebsd-lists-for-dayan-only group
Hello, I've added you to my freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. As a member of this group, you may send messages to the entire group using just one email address: [EMAIL PROTECTED] eGroups also makes it easy to store photos and files, coordinate events, and more. Here's a description of the group: This list is subscribed to various FreeBSD lists only for Dayan. Here's my introductory message for you: Hello, Welcome to the freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. Please take a moment to review this message. To start sending messages to members of this group, simply send email to [EMAIL PROTECTED] If you do not wish to belong to freebsd-lists-for-dayan-only, you may unsubscribe by sending an email to [EMAIL PROTECTED] You may also visit the eGroups web site to modify your subscriptions: http://www.egroups.co.uk/mygroups Regards, Moderator, freebsd-lists-for-dayan-only TO START SENDING messages to members of this group, simply send email to [EMAIL PROTECTED] If you do not wish to belong to the freebsd-lists-for-dayan-only group, you can unsubscribe by replying to this message, or by sending an email to [EMAIL PROTECTED] Regards, Moderator, freebsd-lists-for-dayan-only SPECIAL NOTE FROM eGroups: Because eGroups values your privacy, it is a violation of our service rules for moderators to add subscribers to a group against their wishes. If you feel this has happened, please notify us at [EMAIL PROTECTED] P.S. If you would like to learn more about the freebsd-lists-for-dayan-only group, please visit http://www.egroups.co.uk/group/freebsd-lists-for-dayan-only and enter the following sign-in information: Email address: [EMAIL PROTECTED] Password: yrlacmxklfugtlv This password has been randomly generated for you. Once you have signed in, you should change your password by visiting http://www.egroups.co.uk/myprofile To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: timing question
* Weiguang SHI [EMAIL PROTECTED] [010807 11:11] wrote: From: Alfred Perlstein [EMAIL PROTECTED] To: Jeff Behl [EMAIL PROTECTED] CC: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Re: timing question Date: Mon, 6 Aug 2001 14:49:55 -0500 * Jeff Behl [EMAIL PROTECTED] [010806 12:48] wrote: please excuse and direct me to the right place if this isn't the appropriate place to post this sort of question we're looking into moving to freebsd (yea!), but found the following problem. It seems that the shortest amount of time the below code will sleep for is 20 seconds! any call to nanosleep for 5,10, etc miliseconds returns a 20 ms delay. are we doing something wrong? You may have to increase the kernel value for HZ so that you get more fine grained clock interrupts. I didn't look at the code but if increasing the value of 'hz' will result in more clock-interrupts/sec thus more overhead, wouldn't it be better to auto-adjust the clock-interrupt rate somewhere in the OS to clock-interrupt at big strides in the beginning but at finer-grained interval as the actual timeout event approaches? Yes, but that's not trivial, several places in the kernel call tsleep(9) with a timeout value of 5 * hz to mean 5 seconds, those places would probably have to be fixed up or something done not to prematurely trigger them waking up. I guess the clock code could realize it's in an accelerated state and not update the variables that could cause problems, basically only look for people who need the higher resolution interrupts. got diffs ? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
: It also has the unfortunate property of locking us into virtual : wire mode, when in fact Microsoft demonstrated that wiring down : interrupts to particular CPUs was good practice, in terms of : assuring best performance. Specifically, running in virtual : wire mode means that all your CPUs get hit with the interrupt, : whereas running with the interrupt bound to a particular CPU : reduces the overall overhead. Even what we have today, with : the big giant lock and redirecting interrupts to the CPU in : the kernel is better than that... : : Terry, this is *total* garbage. : : Just so you know, ok? : :What this, exactly? : :That virtual wire mode is actually a bad idea for some :applications -- specifically, high speed networking with :multiple gigabit ethernet cards? All the cpu's don't get the interrupt, only one does. :That Microsoft demonstrated that wiring down interrupts :to a particular CPU was a good idea, and kicked both Linux' :and FreeBSD's butt in the test at ZD Labs? Well, if you happen to have four NICs and four CPUs, and you are running them all full bore, I would say that wiring the NICs to the CPUs would be a good idea. That seems like a rather specialized situation, though. -Matt :That taking interrupts on a single directed CPU is better :than taking an IPI on all your CPUs, and then sorting out :who's going to handle the interrupt? :... : :-- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
At 12:39 AM -0700 8/7/01, Mike Smith wrote: It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with the big giant lock and redirecting interrupts to the CPU in the kernel is better than that... Terry, this is *total* garbage. Just so you know, ok? There are people on this list besides Terry. Terry has taken the time to refer to a few URL's, and remind us of a benchmark that I (for one) do remember, and I do remember Windows doing quite well on it. Maybe that benchmark was bogus for some reason, but I seem to remember several freebsd developers taking it seriously at the time. So, could you at least fill in what part of the above is total garbage? Throw in a few insults to Terry if it makes you feel better for some reason, but raise the level of information content a little for the rest of us? You quoted several distinct comments of Terry's -- were all of them garbage? It might very well be that all of Terry's comments were in fact garbage, but from the sidelines I'd appreciate a little more in the way of technical details. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
At 9:55 AM -0700 8/7/01, Matt Dillon wrote: : It also has the unfortunate property of locking us into virtual : wire mode, when in fact Microsoft demonstrated that wiring down : interrupts to particular CPUs was good practice, in terms of : assuring best performance. [...] : : Terry, this is *total* garbage. : : Just so you know, ok? : :What this, exactly? : :That virtual wire mode is actually a bad idea for some :applications -- specifically, high speed networking with :multiple gigabit ethernet cards? All the cpu's don't get the interrupt, only one does. :That Microsoft demonstrated that wiring down interrupts :to a particular CPU was a good idea, and kicked both Linux' :and FreeBSD's butt in the test at ZD Labs? Well, if you happen to have four NICs and four CPUs, and you are running them all full bore, I would say that wiring the NICs to the CPUs would be a good idea. That seems like a rather specialized situation, though. Okay, that's helpful to sort out the discussion. I'd agree that is a specialized situation, one which wouldn't be critical to many freebsd users. Is Terry right that the current strategy will lock us into virtual wire mode, in some way which means that this specialized situation CANNOT be handled? (it would be fine if it were handled via some specialized kernel option, imo. I'm just wondering what the limitations are. I do not mean to imply we should follow some different strategy here, I'm just wondering...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Kernel stack size
Hi! I'm developing some code running in kernel that use a lot of stack. And it seems i run into stack overflow. This results in some proc structure related parts overwrite (particulary p-p_stats-p_timer[ITIMER_PROF]) and unexpected signals. (Otherwise, it usually page faults inside swi_net_next()) Could somebody explain how this can happen (i thought i would panic and say ``stack oveflow'') and how this can be avoided? Thanks in forward! Bye! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
:I'd agree that is a specialized situation, one which wouldn't :be critical to many freebsd users. Is Terry right that the :current strategy will lock us into virtual wire mode, in :some way which means that this specialized situation CANNOT :be handled? : :(it would be fine if it were handled via some specialized :kernel option, imo. I'm just wondering what the limitations :are. I do not mean to imply we should follow some different :strategy here, I'm just wondering...) : :-- :Garance Alistair Drosehn= [EMAIL PROTECTED] In -current there is nothing preventing us from wiring interrupt *threads* to cpus. Wiring the actual interrupts themselves might or might not yield a performance improvement beyond that. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: dmesg behaviour
this is a wonderful feature that has saved my butt many times (working in the kernel it's REALLY nice to have the last panic message in the dmesg buffer.) learn to love it.. :-) On Tue, 7 Aug 2001, Koster, K.J. wrote: Dear, On the supermicro systems, we may see the information from the last 3 boots! I see the lines: syncing disks... done Rebooting... and then we go right into the next boot. At present, one of the machines shows all the detail from 2.75 reboots. How and why is it doing this, and how do I make it stop? FWIW, FreeBSD/alpha also exhibits this behaviour. Perhaps it's better to adapt your tools to cope to improve their portability between FreeBSD-supported architectures? Kees Jan = You can't have everything. Where would you put it? [Steven Wright] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dmesg behaviour
this is a wonderful feature that has saved my butt many times (working in the kernel it's REALLY nice to have the last panic message in the dmesg buffer.) learn to love it.. :-) I can see the benefits. I will re-write the programs and scripts that eat the dmesg output to look for the last boot, but I'm concerned that the behavior is different on different platforms. I really hate mysterious platform differences. Thanks, -Les -- Les BiffleCommunity Service... Just Say NO! (480) 585-4099[EMAIL PROTECTED] http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dmesg behaviour
In message [EMAIL PROTECTED], Les Biffle writes: this is a wonderful feature that has saved my butt many times (working in the kernel it's REALLY nice to have the last panic message in the dmesg buffer.) learn to love it.. :-) I can see the benefits. I will re-write the programs and scripts that eat the dmesg output to look for the last boot, but I'm concerned that the behavior is different on different platforms. I really hate mysterious platform differences. The console-log code is machine-independent apart from the initial allocation of the space, so don't expect differences in this area. -- 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: Kernel stack size
the kernel stack is a VERY LIMITED resource basically you have about 4 or 5 Kbytes per process. if you overflow it you write over your signal information.. you should MALLOC space and use a pointer to it.. On Wed, 8 Aug 2001, Semen A. Ustimenko wrote: Hi! I'm developing some code running in kernel that use a lot of stack. And it seems i run into stack overflow. This results in some proc structure related parts overwrite (particulary p-p_stats-p_timer[ITIMER_PROF]) and unexpected signals. (Otherwise, it usually page faults inside swi_net_next()) Could somebody explain how this can happen (i thought i would panic and say ``stack oveflow'') and how this can be avoided? Thanks in forward! Bye! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dmesg behaviour
sorry if that came across a bit rough... I just know that I LOVE that feature. (you don't get it on machines that clear ram between reboots) On Tue, 7 Aug 2001, Les Biffle wrote: this is a wonderful feature that has saved my butt many times (working in the kernel it's REALLY nice to have the last panic message in the dmesg buffer.) learn to love it.. :-) I can see the benefits. I will re-write the programs and scripts that eat the dmesg output to look for the last boot, but I'm concerned that the behavior is different on different platforms. I really hate mysterious platform differences. Thanks, -Les -- Les BiffleCommunity Service... Just Say NO! (480) 585-4099[EMAIL PROTECTED] http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
That Microsoft demonstrated that wiring down interrupts to a particular CPU was a good idea, and kicked both Linux' and FreeBSD's butt in the test at ZD Labs? No, Terry, this is not what was demonstrated by those tests. Will this myth never die? Do Mike and I have to write up a nice white paper? :) The environment was ridigly specified: quad cpu box, four eepro 100mb interfaces, and a _heavy_ load of short lived connections fetching static cached content. The test was clearly designed to stress concurrency in the network stack, with heavy low latency interrupt load. Neither Linux nor FreeBSD could do this well at the time. There was a service pack issed a few months before the test that 'threaded' NT's stack.. It was not a mistake that the rules of the tests forbid doing the sane thing and running on a system with a single very fast cpu, lots of mem, and gigabit interface with an actual published interface for coalescing interrupts. That would have performed better and been cheaper. Thats what pisses me off about the tests to this day. The problem people are faced with is is how do I serve this static content reliably and cheaply, not, what OS should I serve my content with, now that I've bought this ridiculous machine?. Its sad that people consistently insist on drawing insane conclusions from these benchmark events. -- zach To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel stack size
Hi! Thanks for light speed response! On Tue, 7 Aug 2001, Julian Elischer wrote: the kernel stack is a VERY LIMITED resource basically you have about 4 or 5 Kbytes per process. Oops... And there is no hope to enlarge it? if you overflow it you write over your signal information.. That's what i'm seeing. SIGPROF, particulary. you should MALLOC space and use a pointer to it.. But this is loss of speed, isn't it? Bye! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
Matt Dillon wrote: :What this, exactly? : :That virtual wire mode is actually a bad idea for some :applications -- specifically, high speed networking with :multiple gigabit ethernet cards? All the cpu's don't get the interrupt, only one does. I think that you will end up taking an IPI (Inter Processor Interrupt) to shoot down the cache line during an invalidate cycle, when moving an interrupt processing thread from one CPU to another. For multiple high speed interfaces (disk or network; doesn't matter), you will end up burining a *lot* of time, without a lockdown. You might be able to avoid this by doing some of the tricks I've discussed with Alfred to ensure that there is no lock contention in the non-migratory case for KSEs (or kernel interrupt threads) to handle per CPU scheduling, but I think that the interrupt masking will end up being very hard to manage, and you will get the same effect as locking the interrupt to a particular CPU... if you asre lucky. Any case which _did_ invoke a lock and resulted in contention would require at least a barrier instruction; I guess you could do it in a non-cacheable page to avoid the TLB interaction, and another IPI for an update or invalidate cycle for the lock, but then you are limited to memory speed, which is getting down to around a factor of 10 (133MHz) slower than CPU speed, these days, and that's actually one heck of a stall hit to take. :That Microsoft demonstrated that wiring down interrupts :to a particular CPU was a good idea, and kicked both Linux' :and FreeBSD's butt in the test at ZD Labs? Well, if you happen to have four NICs and four CPUs, and you are running them all full bore, I would say that wiring the NICs to the CPUs would be a good idea. That seems like a rather specialized situation, though. I don't think so. These days, interrupt overhead can come from many places, including intentional denial of service attacks. If you have an extra box around, I'd suggest that you install QLinux, and benchmark it side by side against FreeBSD, under an extreme load, and watch the FreeBSD system's performance fall off when interrupt overhead becomes so high that NETISR effectively never gets a chance to run. I also suggest using 100Base-T cards, since the interrupt coelescing on Gigabit cards could prevent you from observing the livelock from interrupt overload, unless you could load your machine to full wire speed (~950Mbits/S) so that your PCI bus transfer rate becomes a barrier. I know you were involved in some of the performance tuning that was attempted immediately after the ZD Labs tests, so I know you know this was a real issue; I think it still is. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel stack size
On Wed, 8 Aug 2001, Semen A. Ustimenko wrote: Hi! Thanks for light speed response! On Tue, 7 Aug 2001, Julian Elischer wrote: the kernel stack is a VERY LIMITED resource basically you have about 4 or 5 Kbytes per process. Oops... And there is no hope to enlarge it? none really. that's the way it is in all kernels.. The kernel is a very limited environment. if you overflow it you write over your signal information.. That's what i'm seeing. SIGPROF, particulary. you should MALLOC space and use a pointer to it.. But this is loss of speed, isn't it? a little but maybe not as much as you think.. malloc is pretty quick. If you are doing it a lot, you might even consider caching the memory blocks.. Bye! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
Zach Brown wrote: That Microsoft demonstrated that wiring down interrupts to a particular CPU was a good idea, and kicked both Linux' and FreeBSD's butt in the test at ZD Labs? No, Terry, this is not what was demonstrated by those tests. Will this myth never die? Do Mike and I have to write up a nice white paper? :) That would be nice, actually. The environment was ridigly specified: quad cpu box, four eepro 100mb interfaces, and a _heavy_ load of short lived connections fetching static cached content. The test was clearly designed to stress concurrency in the network stack, with heavy low latency interrupt load. Neither Linux nor FreeBSD could do this well at the time. There was a service pack issed a few months before the test that 'threaded' NT's stack.. It was not a mistake that the rules of the tests forbid doing the sane thing and running on a system with a single very fast cpu, lots of mem, and gigabit interface with an actual published interface for coalescing interrupts. That would have performed better and been cheaper. I have soft interrupt coelescing changes for most FreeBSD drivers written by Bill Paul; the operation is trivial, and Bill has structured his drivers well for doing that sort of thing. I personally don't think the test was unfair; it seems to me to be representative of most web traffic, which averages 8k a page for most static content, according to published studies. Thats what pisses me off about the tests to this day. The problem people are faced with is is how do I serve this static content reliably and cheaply, not, what OS should I serve my content with, now that I've bought this ridiculous machine?. 8-) 8-). Its sad that people consistently insist on drawing insane conclusions from these benchmark events. I think that concurrency in the TCP stack is something that needs to be addressed; I'm glad they ran the benchmark, if only for that. Even if we both agree on the conclusions, agreeing isn't going to change people's perceptions, but beating them on their terms _will_, so it's a worthwhile pursuit. I happen to agree that their test indicated some shortcomings in the OS designs; regardless of whether we think they were carefully chosen to specifically emphasize those shortcomings, it doesn't change the fact that they are shortcomings. There's no use crying over spilt milk: the question is what can be done about it, besides trying to deny the validity of the tests. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel stack size
Julian Elischer wrote: the kernel stack is a VERY LIMITED resource basically you have about 4 or 5 Kbytes per process. if you overflow it you write over your signal information.. you should MALLOC space and use a pointer to it.. Would adding an unmapped or read-only guard page be unreasonable? The only thing I could see it doing would be panic'ing, so it's not like it'd be possible to dump the process, without handling the double fault and hoping it doesn't go over 4k of overage (or you'd need 2...N guard pages). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
On Tue, 7 Aug 2001, Terry Lambert wrote: Matt Dillon wrote: All the cpu's don't get the interrupt, only one does. I think that you will end up taking an IPI (Inter Processor Interrupt) to shoot down the cache line during an invalidate cycle, when moving an interrupt processing thread from one CPU to another. You have a lot of fantasy today. You may want to consider reading one of the white papers you referred us to with so much enthusiasm and trying again later ;) Well, if you happen to have four NICs and four CPUs, and you are running them all full bore, I would say that wiring the NICs to the CPUs would be a good idea. That seems like a rather specialized situation, though. I don't think so. These days, interrupt overhead can come from many places, Exactly. You never know where your interrupts come from, so wiring them in a fixed setup really isn't going to do you much good in the generic case. Now if you want to optimise your source code for something like a Mindcraft benchmark ... regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel stack size
From: Julian Elischer [EMAIL PROTECTED] To: Semen A. Ustimenko [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Kernel stack size Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT) On Wed, 8 Aug 2001, Semen A. Ustimenko wrote: Hi! Thanks for light speed response! On Tue, 7 Aug 2001, Julian Elischer wrote: the kernel stack is a VERY LIMITED resource basically you have about 4 or 5 Kbytes per process. Oops... And there is no hope to enlarge it? none really. that's the way it is in all kernels.. The kernel is a very limited environment. How about just changing UPAGES to n (n2)? Weiguang _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
: :Matt Dillon wrote: : :What this, exactly? : : : :That virtual wire mode is actually a bad idea for some : :applications -- specifically, high speed networking with : :multiple gigabit ethernet cards? : : All the cpu's don't get the interrupt, only one does. : :I think that you will end up taking an IPI (Inter Processor :Interrupt) to shoot down the cache line during an invalidate :cycle, when moving an interrupt processing thread from one :CPU to another. For multiple high speed interfaces (disk or :network; doesn't matter), you will end up burining a *lot* :of time, without a lockdown. Cache line invalidation does not require an IPI. TLB shootdowns require IPIs. TLB shootdowns are unrelated to interrupt threads, they only occur when shared mmu mappings change. Cache line invalidation can waste cpu cycles -- when cache mastership changes occur between cpus due to threads being switched between cpus. I consider this a serious problem in -current. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Linksys WDT11/WPC11 Combo
Steve,
Here's a patch I did against -STABLE circa mid-June. It probably won't
apply cleanly today -- I think the 2x MAC address read has been MFC'd.
Pretty minor changes, though; it works great for me.
Enjoy,
Eric
Steve Logue wrote:
Sorry if this is a duplicate
Hello,
Does anyone have any patches for preliminary support of the Linksys
WDT11/WPC11 wireless ethernet combo? The WDT card uses the PLX PCI9052
chipset and shows up under -STABLE's dmesg as:
pci0: unknown card (vendor=0x16ab, dev=0x1102) at 19.0 irq 12
With what I have been reading so far on the PLX thread, I appear to have
a different dev number. Most people have talked about dev=1101, but I
have dev=1102. Is this a new rev of the board? How can I get this
working?
Patches for -CURRENT or -STABLE would be appreciated.
-STEVEl
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--- share/man/man4/wi.save Sun Jun 10 06:13:04 2001
+++ share/man/man4/wi.4 Sun Jun 10 06:09:01 2001
@@ -53,6 +53,12 @@ Both the original
2Mbps WaveLAN/IEEE cards and the newer 6Mbps WaveLAN/IEEE Turbo
adapters are supported.
.Pp
+Additionally, the
+.Nm
+driver supports PCI adapters for the cards based PLX Techology's PCI 9052,
+such as the Linksys WDT11 Wireless PCI Adapter which works in conjunction
+with the WPC11 Wireless Network PC Card.
+.Pp
The core of the WaveLAN/IEEE is the Lucent Hermes controller.
All
host/device interaction is via programmed I/O with the Hermes.
--- sys/i386/isa/if_wi.save Sat Jun 9 23:51:31 2001
+++ sys/i386/isa/if_wi.cSun Jun 10 06:31:10 2001
@@ -230,6 +230,7 @@ wi_pci_probe(dev)
struct wi_softc *sc;
sc = device_get_softc(dev);
+ /* XXX Getting a little unwieldy... */
if ((pci_get_vendor(dev) == WI_PCI_VENDOR_EUMITCOM)
(pci_get_device(dev) == WI_PCI_DEVICE_PRISM2STA)) {
sc-wi_prism2 = 1;
@@ -237,6 +238,20 @@ wi_pci_probe(dev)
PRISM2STA PCI WaveLAN/IEEE 802.11);
return (0);
}
+ if ((pci_get_vendor(dev) == WI_PCI_VENDOR_LINKSYS)
+ (pci_get_device(dev) == WI_PCI_DEVICE_WDT11)) {
+ sc-wi_prism2 = 1;
+ device_set_desc(dev,
+ Linksys WDT11 Wireless PCI Adapter);
+ return (0);
+ }
+ if ((pci_get_vendor(dev) == WI_PCI_VENDOR_GLOBALSUN)
+ (pci_get_device(dev) == WI_PCI_DEVICE_GL24110P)) {
+ sc-wi_prism2 = 1;
+ device_set_desc(dev,
+ Global Sun GL24110P Wireless PCI Adapter);
+ return (0);
+ }
return(ENXIO);
}
@@ -399,9 +414,15 @@ wi_generic_attach(device_t dev)
/* Reset the NIC. */
wi_reset(sc);
- /* Read the station address. */
+ /*
+* Read the station address.
+* And do it twice. I've seen PRISM-based cards that return
+* an error when trying to read it the first time, which causes
+* the probe to fail.
+*/
mac.wi_type = WI_RID_MAC_NODE;
mac.wi_len = 4;
+ wi_read_record(sc, (struct wi_ltv_gen *)mac);
if ((error = wi_read_record(sc, (struct wi_ltv_gen *)mac)) != 0) {
device_printf(dev, mac read failed %d\n, error);
wi_free(dev);
--- sys/i386/isa/if_wireg.save Sat Jun 9 23:51:41 2001
+++ sys/i386/isa/if_wireg.h Sun Jun 10 06:27:17 2001
@@ -147,7 +147,12 @@ struct wi_softc{
#define WI_PCI_IORES 0x1C
#define WI_PCI_VENDOR_EUMITCOM 0x1638
-#define WI_PCI_DEVICE_PRISM2STA0x1100
+#define WI_PCI_DEVICE_PRISM2STA0x1100 /* Eumitcom PCI WL11000 */
+#define WI_PCI_VENDOR_LINKSYS 0x16AB
+#define WI_PCI_DEVICE_WDT110x1102 /* Linksys PCI WPC11 */
+#define WI_PCI_VENDOR_GLOBALSUN0x16AB
+#define WI_PCI_DEVICE_GL24110P 0x1101 /* Global Sun GL24110P */
+
#define WI_HFA384X_SWSUPPORT0_OFF 0x28
#define WI_PRISM2STA_MAGIC 0x4A2D
Re: Allocate a page at interrupt time
On Tue, Aug 07, 2001 at 12:19:01PM -0700, Matt Dillon wrote: Cache line invalidation does not require an IPI. TLB shootdowns require IPIs. TLB shootdowns are unrelated to interrupt threads, they only occur when shared mmu mappings change. Cache line invalidation can waste cpu cycles -- when cache mastership changes occur between cpus due to threads being switched between cpus. I consider this a serious problem in -current. I don't think it's fair to consider this a serious problem seeing as how, as far as I'm aware, we've intended to eventually introduce code that will favor keeping threads running on one CPU on that same CPU as long as it is reasonable to do so (which should be most of the time). I think after briefly discussing with Alfred on IRC that Alfred has some CPU affinity patches on the way, but I'm not sure if they address thread scheduling with the above intent in mind or if they merely introduce an _interface_ to bind a thread to a single CPU. -Matt -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel stack size
yes you could do that but N is still goin gto be small when compared to teh size of a userland stack, and all upages come out of a KVM object which is limitted. When we get threads, we have to be able to have a hundred stacks per process if things get silly. Actually in teh KSE kernel I'm working on UPAGES is defined as (UAREA_PAGES+KSTATCK_PAGES) so increasing KSTACK_PAGES (presently 1) is what you would want to do.. it's still bad practice (particularly on 4.x) to put a lot of stuff on the kernel stack. Also, remember that if you are writing a device driver, the interrupt half of your driver will not always run on the same stack as the top half, so things that are passed between them can't be stored there.. (not to mention if the process gets swapped out) On Tue, 7 Aug 2001, Weiguang SHI wrote: From: Julian Elischer [EMAIL PROTECTED] To: Semen A. Ustimenko [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Kernel stack size Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT) On Wed, 8 Aug 2001, Semen A. Ustimenko wrote: Hi! Thanks for light speed response! On Tue, 7 Aug 2001, Julian Elischer wrote: the kernel stack is a VERY LIMITED resource basically you have about 4 or 5 Kbytes per process. Oops... And there is no hope to enlarge it? none really. that's the way it is in all kernels.. The kernel is a very limited environment. How about just changing UPAGES to n (n2)? Weiguang _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
* Bosko Milekic [EMAIL PROTECTED] [010807 14:51] wrote:
On Tue, Aug 07, 2001 at 12:19:01PM -0700, Matt Dillon wrote:
Cache line invalidation does not require an IPI. TLB
shootdowns require IPIs. TLB shootdowns are unrelated to
interrupt threads, they only occur when shared mmu mappings
change. Cache line invalidation can waste cpu cycles --
when cache mastership changes occur between cpus due to
threads being switched between cpus. I consider this a
serious problem in -current.
I don't think it's fair to consider this a serious problem seeing as
how, as far as I'm aware, we've intended to eventually introduce code that will
favor keeping threads running on one CPU on that same CPU as long as it is
reasonable to do so (which should be most of the time).
I think after briefly discussing with Alfred on IRC that Alfred has
some CPU affinity patches on the way, but I'm not sure if they address
thread scheduling with the above intent in mind or if they merely introduce
an _interface_ to bind a thread to a single CPU.
They do both. :) You can bind a process to a runqueue _and_ at the
same time as long as a process on another CPU doesn't have a much
higher priority we'll take from our local pool.
Basically we give processes that last ran on our own CPU a false
priority boost.
http://people.freebsd.org/~alfred/bind_cpu.diff
+ cpu = PCPU_GET(cpuid);
+ pricpu = runq_findbit(runqcpu[cpu]);
+ pri = runq_findbit(rq);
+ CTR2(KTR_RUNQ, runq_choose: pri=%d cpupri=%d, pri, pricpu);
+ if (pricpu != -1 (pricpu pri || pri == -1)) {
+ pri = pricpu;
+ rqh = runqcpu[cpu].rq_queues[pri];
+ } else if (pri != -1) {
+ rqh = rq-rq_queues[pri];
+ } else {
+ CTR1(KTR_RUNQ, runq_choose: idleproc pri=%d, pri);
+ return (PCPU_GET(idleproc));
+ }
+ p = TAILQ_FIRST(rqh);
Actually I think this patch is stale, it doesn't have
the priority boost, but basically you can put it in the
if (pricpu != -1 (pricpu pri || pri == -1)) {
clause sort of like this:
if (pricpu != -1 (pricpu - FUDGE pri || pri == -1)) {
Where FUDGE is the priority boost you want to give local processes.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
On Tue, Aug 07, 2001 at 02:11:10AM -0700, Terry Lambert wrote: Can you name one SMP OS implementation that uses an interrupt threads approach that doesn't hit a scaling wall at 4 (or fewer) CPUs, due to heavier weight thread context switch overhead? Solaris, if I remember my Vahalia book correctly (isn't that a favorite of yours?). -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
-Stable, apache, ldap and shlibs
Who is the expert on apache, modules and shlibs? (I'll go offline to discuss the problem if I can find an appropriate person.. (can't get ldap module to work with apache under freebsd.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ypserv update
Ok... I have just finished the first step in a rewrite of the hash routines for berkleydb (read-only at this point), and I have ypserv compiled using them. So far so good :). And ypserv uses a _lot_ less CPU resources now. (I have totally removed all of the buffer management code in berkley db, and I am using mmap() exclusively. Still to be done is to impliment R_CURSOR type, that will improve ypserv's performance quite a bit in environments like ours.). If all goes well (no bugs found), I will put this up on my website in source-only form tonight. Maybe be added to ports tonight too. I am eagerly looking for helpers to complete the hash rewrite, and then the rest of berkley DB as well. File format information would be very usefull, the stuff that is included with BDB is lacking. -- 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
Why page enable in Kernel space?
In general a address in a process is just a linear address whichrefer to physical address indirectly by page directory. This is reasonable in user space. However is it necessary to do such thing in kernel? It is sure to have penalty when converting a linear address to physical thing. Is it worth doing such thing in kernel. I think the performance is the most important in kernel, other thing is second. I remember in linux linear address is real physical address in kernel space(is it true?). Why freebsd does not do in the same way? craiglei
GRRRR (ypserv)
I am apparently bug-compatible with the original too, though it took longer to trip over it (and the code runs LOTS faster :)... So probably not tonight. I am going to be placing debugging statements in the code to see if I can figure out where information is being stepped on.) -- 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: Why page enable in Kernel space?
On Wed, 8 Aug 2001, craig wrote: In general a address in a process is just a linear address which refer to physical address indirectly by page directory. This is reasonable in user space. However is it necessary to do such thing in kernel? It is sure to have penalty when converting a linear address to physical thing. Is it worth doing such thing in kernel. I think the performance is the most important in kernel, other thing is second. I remember in linux linear address is real physical address in kernel space(is it true?). No Why freebsd does not do in the same way? it wouldn't work.. craiglei To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why page enable in Kernel space?
On Wed, 8 Aug 2001, craig wrote: In general a address in a process is just a linear address which refer to physical address indirectly by page directory. This is reasonable in user space. However is it necessary to do such thing in kernel? It is sure to have penalty when converting a linear address to physical thing. Is it worth doing such thing in kernel. I think the performance is the most important in kernel, other thing is second. I remember in linux linear address is real physical address in kernel space(is it true?). Why freebsd does not do in the same way? To add a bit more.. the kernel uses 4MB of linear physical memory for it's text. (this saves a lot of TLBs but still requires paging to be on. craiglei To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dmesg behaviour
As far as I understand, this feature works only if the machine does not clear its memory upon reboot. AT compatibles clear memory during the BIOS POST, thus, we don't see console log from the previous boot on the i386 platform. Kazu sorry if that came across a bit rough... I just know that I LOVE that feature. (you don't get it on machines that clear ram between reboots) On Tue, 7 Aug 2001, Les Biffle wrote: this is a wonderful feature that has saved my butt many times (working in the kernel it's REALLY nice to have the last panic message in the dmesg buffer.) learn to love it.. :-) I can see the benefits. I will re-write the programs and scripts that eat the dmesg output to look for the last boot, but I'm concerned that the behavior is different on different platforms. I really hate mysterious platform differences. Thanks, -Les -- Les BiffleCommunity Service... Just Say NO! (480) 585-4099[EMAIL PROTECTED] http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
On Tuesday, 7 August 2001 at 1:58:21 -0700, Terry Lambert wrote: Bosko Milekic wrote: I keep wondering about the sagicity of running interrupts in threads... it still seems like an incredibly bad idea to me. I guess my major problem with this is that by running in threads, it's made it nearly impossibly to avoid receiver livelock situations, using any of the classical techniques (e.g. Mogul's work, etc.). References to published works? Just do an NCSTRL search on receiver livelock; you will get over 90 papers... http://ncstrl.mit.edu/ See also the list of participating institutions: http://ncstrl.mit.edu/Dienst/UI/2.0/ListPublishers It won't be that hard to find... Mogul has only published 92 papers. 8-) So much data, in fact, that you could hide anything behind it. Would you like to be more specific? It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual Can you point us at any concrete information that shows this? Specifically, without being Microsoft biased (as is most data published by Microsoft)? -- i.e. preferably third-party performance testing that attributes wiring down of interrupts to particular CPUs as _the_ performance advantage. FreeBSD was tested, along with Linux and NT, by Ziff Davis Labs, in Foster city, with the participation of Jordan Hubbard and Mike Smith. You can ask either of them for the results of the test; only the Linux and NT numbers were actually released. This was done to provide a non-biased baseline, in reaction to the Mindcraft benchmarks, where Linux showed so poorly. They ran quad ethernet cards, with quad CPUs; the NT drivers wired the cards down to seperate INT A/B/C/D interrupts, one per CPU. You carefully neglect to point out that this was the old SMP implementation. I think this completely invalidates any point you may have been trying to make. wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with Obviously. I mention it because this is the direction FreeBSD appears to be moving in. Right now, Intel is shipping with seperate PCI busses; there is one motherboard from their serverworks division that has 16 seperate PCI busses -- which means that you can do simultaneous gigabit card DMA to and from memory, without running into bus contention, so long as the memory is logically seperate. NT can use this hardware to its full potential; FreeBSD as it exists, can not, and FreeBSD as it appears to be heading today (interrupt threads, etc.) seems to be in the same boat as Linux, et. al.. PCI-X will only make things worse (8.4 gigabit, burst rate). What do interrupt threads have to do with this? Terry, we've done a lot of thinking about performance implications over the last 2 years, including addressing all of the points that you appear to raise. A lot of it is in the archives. It's quite possible that we've missed something important that you haven't. But if that's the case, we'd like you to state it. All I see is you coming in, waving your hands and shouting generalities which don't really help much. The fact that people are still listening is very much an indication of the hope that you might come up with something useful. But pointing to 92 papers and saying it's in there [somewhere] isn't very helpful. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
¡îÓòÃû×¢²á¿Õ¼äÉêÇë¸÷ËÍÈý¸ö´Î¼¶ÓòÃû»¹Ãâ·ÑÊÔÓÃ!
×ð¾´µÄÅóÓÑ£¬ÄúºÃ£¡ ·Ç³£¸ÐлÄúµÄä¯ÀÀ£¬Èç¹ûÄúÕýΪѰÕÒÒ»¸ö¸üºÃµÄISP¶ø·³ÄÕ£¬ÄÇôÎÒÃÇÍøÂçʱ´úhttp://www.now.net.cnΪÄúÌṩÁË×î¼ÑµÄÑ¡Ôñ£¡ ¡î ÓòÃû×¢²á ×¢²áÓòÃûÔùËÍ3¸ö´Î¼¶ÓòÃû(´øVDNS)£¡ ͬʱÉêÇë¿Õ¼äÔÙÔùËÍ3¸ö´Î¼¶ÓòÃû£¡ ¡îÐéÄâÖ÷»ú Ò» ÌضàÓÅ»Ý ·²ÔÚ8.1µ½9.1×¢²áÓòÃûͬʱÉêÇë¿Õ¼äËÍ6¸ö´Î¼¶ÓòÃû£¡µÈÓÚÒ»¸öÓòÃû¾ÍÄÜͬʱ½¨6¸öÍøÕ¾£¡Í¬Ê±¼ÓËÍ15¸öÉÌÓÃÓʼþÕ˺ţ¡ ¶þ ³¬µÍÌØ¼Û 280Ôª£¡Äú¿ÉÒÔÁ¢¿ÌÓµÓÐÎȶ¨¶ø¿ìËÙµÄ100MÐéÄâÖ÷»ú¿Õ¼ä!»¹ÓÌԥʲôÄØ£¬¸Ï¿ìÐж¯°É£¡ Èý ³¹µ×½â·Å ÏÖÔÚÌ컥¿Æ¼¼µÄASPºÍACCESSÊý¾Ý¿âÈ«Ã濪·Å£¬Ö»Ðè100Ôª¾ÍÈÃÄúµÄÍøÕ¾ÓµÓÐÊý¾Ý¿â¡£ ²¢ÓÐÌṩCGI PERL PHP JSP µÈÒ»Ìå¸ß¼¶¿Õ¼ä.ËùÓпռäʵʱ¿ªÍ¨Ãâ·ÑÊÔÓÃ15Ìì! ¡î¡î»ðºìÏÄÈÕ¡±Ö÷»úÍйÜÓÅ»Ýì«·çÈ«ÃæµÇ½£¬Ç¿´ó¡¢¸ß±ê×¼µÄµçÐż¶Êý¾ÝÖÐÐÄ»ú·¿£¬¸ß°²È«ÌØÐÔ¡¢¸ß·þÎñ±ê×¼¡¢ ÔÙ¼ÓÉϺÏÀíµÄ¼Û¸ñ£¬Ïò¹ã´ó¿Í»§Ìṩ¸ßÐԼ۱ȵķþÎñ¡£Ïê¼ûhttp://idc.now.net.cn ¡î¡îͬʱÎÒÃÇÏò¹ã´ó¸÷½ì³ÏÕ÷´úÀí£¬ÈȳÀÑûÇëÄú¼ÓÈëÍøÂçʱ´úµÄÒµÎñºÏ×÷ÕóÓª£¬¹²Í¬·ÖÏíÍøÂçʱ´úµÄÅÓ´ó¿Í»§×ÊÔ´¡£ÏêϸÇë·ÃÎÊÎÒÃÇÍøÕ¾¡£ »òÖ±½ÓÁªÏµÎÒÃÇ: ÇñС½ã [EMAIL PROTECTED] ÁÖÏÈÉú [EMAIL PROTECTED]¡¡ µç»°£º0756-2125583 22216376 ¼¼Êõ²¿£º [EMAIL PROTECTED] [EMAIL PROTECTED] 0756--2216376 2139739 »¶ÓÖÂÐÅ Today's Network [EMAIL PROTECTED] »¶ÓÄú·ÃÎÊÎÒÃǵÄÍøÕ¾ http://www.now.net.cn ÎÒÃÇÒ»Ö±ÒÔרҵ¡¢ÓÅÖÊ¡¢ÁìÏÈΪ×ÚÖ¼£¬ÈȳÏΪÄú·þÎñ£¡ ... ×¢£ºVDNS¿ÉÊÓ»¯ÓòÃû·þÎñÆ÷£¬ÄÜʵÏÖ£Õ£Ò£Ìת·¢¡¢Ö÷»ú£Á¼Ç¼¡¢£Í£ØÓʼþ¼Ç¼¡¢£É£ÐÖ¸Ïò¿ØÖƵȲÙ×÷,¸ü¿ÉÒÔËæÐÄËùÓûµØÔö¼Ó×Ô¼ºµÄ´Î¼¶ÓòÃû£¬°ïÖúÄú½¨Á¢¶à¸öÍøÕ¾£¬Äã¿ÉÒÔÈÃËýÖ¸ÏòÈκοռ䡣 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Tuning the 4.1-R kernel for networking
Hello,
I am using a PIII 550MHz UP system running FreeBSD 4.1-RELEASE. It has
a 3c905B-TX Fast Etherlink XL card.
# ifconfig xl0
xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.34.24.62 netmask 0xfc00 broadcast 10.34.27.255
inet6 fe80::2c0:4fff:fe20:3926%xl0 prefixlen 64 scopeid 0x1
ether 00:c0:4f:20:39:26
media: autoselect (100baseTX full-duplex) status: active
supported media: autoselect 100baseTX full-duplex 100baseTX
10baseT/UTP full-duplex 10baseT/UTP 100baseTX hw-loopback
On this machine I run a program which simulates many (~150) simultaneous
TCP clients. This is actually a multithreaded Linux binary, and one
thread per simulated TCP client is created. After a few seconds the
system runs out of mbuf clusters:
# netstat -m
3231/3392/6144 mbufs in use (current/peak/max):
1641 mbufs allocated to data
182 mbufs allocated to packet headers
1408 mbufs allocated to socket names and addresses
1536/1536/1536 mbuf clusters in use (current/peak/max)
3920 Kbytes allocated to network (98% in use)
96993 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Also, I see a steady stream of these messages on the console:
xl0: no memory for rx list -- packet dropped!
From the xl(4) man page:
xl%d: no memory for rx list The driver failed to allocate an mbuf
for the receiver ring.
Looking at the xl_newbuf() function in the xl driver, there are two
places where this message can be generated. It looks like the problem
is with the second case where the MCLGET fails, since we are running out
of those.
/*
* Initialize an RX descriptor and attach an MBUF cluster.
*/
static int xl_newbuf(sc, c)
struct xl_softc *sc;
struct xl_chain_onefrag *c;
{
struct mbuf *m_new = NULL;
MGETHDR(m_new, M_DONTWAIT, MT_DATA);
if (m_new == NULL) {
printf(xl%d: no memory for rx list --
packet dropped!\n, sc-xl_unit);
return(ENOBUFS);
}
MCLGET(m_new, M_DONTWAIT);
if (!(m_new-m_flags M_EXT)) {
printf(xl%d: no memory for rx list --
packet dropped!\n, sc-xl_unit);
m_freem(m_new);
return(ENOBUFS);
}
m_new-m_len = m_new-m_pkthdr.len = MCLBYTES;
/* Force longword alignment for packet payload. */
m_adj(m_new, ETHER_ALIGN);
c-xl_mbuf = m_new;
c-xl_ptr-xl_frag.xl_addr = vtophys(mtod(m_new, caddr_t));
c-xl_ptr-xl_frag.xl_len = MCLBYTES | XL_LAST_FRAG;
c-xl_ptr-xl_status = 0;
return(0);
}
I increased maxusers to 128 (2560 mbuf clusters) and it ran out of mbuf
clusters again. Then I increased it to 256 (4608 mbuf clusters), with
the same results. I don't have any sense of what is reasonable mbuf
cluster usage for the application that I am running, but the system
never seems to recover from the condition, which would seem to point to
an mbuf cluster leak.
Does this sound like a problem with the driver (mbuf cluster leak), or
with the way that I have tuned this system? (the kernel config file for
this system is attached)
I compiled a debug kernel and panicked the system while it was in the
state described above, in case that is any use. I don't know how to
analyze the crash dump to determine where the problem is. Any
suggestions are welcome.
Thanks,
-brian
--
Brian O'Shea
[EMAIL PROTECTED]
#
# SHAOLIN -- Kernel based on the GENERIC configuration file for FreeBSD/i386
#
machine i386
cpu I686_CPU
ident SHAOLIN
maxusers256
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
#optionsMATH_EMULATE#Support for x87 emulation
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
options MFS #Memory Filesystem
options MD_ROOT #MD is a potential root device
options NFS #Network Filesystem
options NFS_ROOT#NFS usable as root device, NFS required
options MSDOSFS #MSDOS Filesystem
options CD9660 #ISO 9660 Filesystem
options CD9660_ROOT #CD-ROM usable as root, CD9660 required
options PROCFS #Process filesystem
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
Re: Tuning the 4.1-R kernel for networking
* Brian O'Shea [EMAIL PROTECTED] [010807 23:33] wrote: Hello, I am using a PIII 550MHz UP system running FreeBSD 4.1-RELEASE. It has a 3c905B-TX Fast Etherlink XL card. [snip] I increased maxusers to 128 (2560 mbuf clusters) and it ran out of mbuf clusters again. Then I increased it to 256 (4608 mbuf clusters), with the same results. I don't have any sense of what is reasonable mbuf cluster usage for the application that I am running, but the system never seems to recover from the condition, which would seem to point to an mbuf cluster leak. Does this sound like a problem with the driver (mbuf cluster leak), or with the way that I have tuned this system? (the kernel config file for this system is attached) I compiled a debug kernel and panicked the system while it was in the state described above, in case that is any use. I don't know how to analyze the crash dump to determine where the problem is. Any suggestions are welcome. Your system isn't configured for high network throughput, you want to put something like: kern.ipc.nmbclusters=32768 this might also help: net.inet.tcp.tcbhashsize=32768 put those into /boot/loader.conf -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
