Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 03:55:23PM -0400, Daniel Eischen wrote: David also has patches for debugging support at: http://people.freebsd.org/~davidxu/kse/dbg/ Unless David Xu completes full FSF paper work, we can't use his patches. Using them tants us forever in getting stock GDB to support our threading. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 01:48:17PM -0700, Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: Doug Rabson also has basic TLS support working in perforce. What platforms? My understanding was that new binutils and gcc was needed for sparc64 at a minimum. Yes. It's i386 only and not even close to being complete. In fact, there has been discussions that the thread pointer on i386 needs to change. Whether that's the case or not, it's likely that TLS will complicate matters way too much to for it to ever work in 5.3. It'd be nice to get TLS and debugging in before 5.3-release. Yes. Be aware that there is a serious effort to get GDB 6.x into the tree for 5.3. I just asked cvs@ and core@ to advice about importing gdb 6.1 into src/contrib/gdb6. We need to break this vicious circle of people waiting on each other. This came up before and you were already asked not to import into src/contrib/gdb6 (and what email would be sent to Core if you did). Any GDB imports need to go into src/contrib/gdb/. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 02:12:49PM -0700, Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: As with Alpha, the fate of a platform rests on the people who are willing to work on it, not on whether it is in a particular list. Agreed, but it's the projects responsibility to take the tierness and the intend to support multiple platforms serious and not to chicken out at the first signs of complications or hurdles. We labeled sparc64 as a tier 1 platform and we better deal with the consequences. As for alpha, we don't even seem to be able to degrade it to tier 2 without losing face. kris@ has already stopped package builds for it for his own sake. Wake up, people. This is quickly becoming a joke... Right... dons flak jacket Basically only i386 is a Tier 1. The rest is a joke if it is called Tier 1. If only because there are insufficient numbers of committers actively working on the arch. (maybe pc98 should be called Tier 1, I just don't know enough about that one). -- Wilko Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2.1: Mutex/Spinlock starvation?
On Saturday 05 June 2004 04:55 pm, Ali Niknam wrote: Hi Robert, As promised my findings regarding the changes; just came home after a night of trying and praying :) Actually, by default, most mutexes in the system are sleep mutexes, so they sleep on contention rather than spinning. In some cases, this actually hurts more than spinning, because if the mutex is released quickly by the holder, then you pay the context switches which cost more than spinning for the short period of time. You might want to try adding options ADAPTIVE_MUTEXES to your kernel configuration, which will cause mutexes to spin briefly on SMP systems before sleeping, and has been observed to improve performance quite a bit. I tried this; this helps performance a lot, here are the findings: - under all conditions turning on HTT helps a *lot* (which is logical i think) - under non killing load (killing load = load where server would have crashed without this option) it performs much much better - under killing load it performs a lot better, up until a certain level: - a new killing level: from this point onward basically the same thing happens as before.. What i'm guessing is that probably this new killing level occurs when load is so high that the spins 'adapt' into blocks. From your description above I understand that there's a certain timeout when 'spinning' mutexes turn into 'blocking'/'sleeping' mutexes. Is there a way to set this timeout ? I would very much like to try out what would happen if one would set this timeout to a quite high value. There isn't a timeout. Rather, the lock spins so long as the current owning thread is executing on another CPU. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Sun, 2004/06/06 at 14:59:21 -0700, Kris Kennaway wrote: On Sun, Jun 06, 2004 at 03:49:13PM -0600, Scott Long wrote: amd64 is approaching critical mass for tier-1. There are a number of developers that own amd64 hardware now, and a number of users who are asking about it on the mailing lists. Peter is finishing up the last blocking item for it (kld's) not including the observed KSE problems. It's very close and I _will_ hold up the release for it to get done. amd64 is the future of commodity computing and we aren't going to ignore it for 5-STABLE. amd64 has a bug with swapping - when something begins to access swap, the entire system becomes almost entirely unresponsive (e.g. no mouse response for up to 10 seconds) until it stops. Peter has some ideas about it, but it's a serious enough bug that it forced me to stop using amd64 as my desktop machine (hello, kde!). Hmmm, I have encountered a similar problem on sparc64 once; the reason was that vm_pageout_map_deactivate_pages() calls pmap_remove() for the range from the start to the end of the process's vm_map when a process is swapped out. Start and end are VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS respectively, and on 64-bit architectures, that range is very large (128TB on ia64 if I'm not mistaken), so the iteration in pmap_remove() must be carefully designed to make as large steps as possible to avoid long run times (or to not iterate over the range at all if it becomes too large, which we did on sparc64). It seems that the amd64 version of pmap_remove() will essentially always iterate in 2MB (level 2 page table) steps, regardless of whether there is mapping for the respective level 2 table in the table levels above; that means that in the previously mentioned case, the outer loop will usually run for about 67 million iterations (the resident count guard may not be of much use here if a stack page is left at the very end of the address space). Since there are a few memory accesses needed in each iterations, that may already be the cause of such a delay. I have no hardware to test this, so all of the above is just a wild- assed guess; but maybe it is of use (and sorry for the spam if it is not). - Thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ I realized that the purpose of writing is to inflate weak ideas, obscure poor reasoning, and inhibit clarity. -- Calvin and Hobbes ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: general Darwin imports (was Re: Darwin cmd import?)
On Sat, 5 Jun 2004, David Scheidt wrote: Just about all of that is listed as covered by the APSL. (Except GPL'd stuff, it looks like.) I noticed this as well, but if you look at the contents (of libc in this case), there are several */FreeBSD/ directories that contain files that retain their original copyrights, along with patches. -- Matthew George SecureWorks Technical Operations ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
Garance A Drosihn wrote: At 3:46 PM -0600 6/6/04, Scott Long wrote: At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. ... As I said back then, demotion is not a terminal condition, and I would be thrilled if someone comes forward in the future and brings the platform back up to date. I think you have to officially demote it, with emphasis on the point that demotion is not a terminal condition. Then, if some developer(s) show up and implement all the missing pieces, we can happily announce it back in tier 1. But for now, say that it *IS* demoted. Not that you're advocating that we think about maybe demoting it in the future unless someone offers to start looking into the missing pieces. At the moment, it probably also makes sense to demote sparc64, even though I own one of those. Not that we have anything against it, but as a practical matter we haven't hit critical mass on it just yet. Since I am interested in sparc64, I can take that as a goal to help make it a tier-1 platform by 5.4-release... One thing to note is that whatever platforms get dropped from tier-1 status will have a high probablility of not getting updated with the upcoming binutils/gcc/gdb update that is coming. Therefore, if we are going to drop a platform, we had better be very serious about it since bringing it back up might be hard. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Mon, Jun 07, 2004 at 09:37:12AM -0600, Scott Long wrote: One thing to note is that whatever platforms get dropped from tier-1 status will have a high probablility of not getting updated with the upcoming binutils/gcc/gdb update that is coming. Logic dictates that the probability should be 0. One cannot reach tier 1 from any tier 1 if binutils, gcc and gdb are not working. Hence, any tier 2 platform must already be supported by binutils, gcc and gdb. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Monday 07 June 2004 07:33 am, Thomas Moestl wrote: On Sun, 2004/06/06 at 14:59:21 -0700, Kris Kennaway wrote: On Sun, Jun 06, 2004 at 03:49:13PM -0600, Scott Long wrote: amd64 is approaching critical mass for tier-1. There are a number of developers that own amd64 hardware now, and a number of users who are asking about it on the mailing lists. Peter is finishing up the last blocking item for it (kld's) not including the observed KSE problems. It's very close and I _will_ hold up the release for it to get done. amd64 is the future of commodity computing and we aren't going to ignore it for 5-STABLE. amd64 has a bug with swapping - when something begins to access swap, the entire system becomes almost entirely unresponsive (e.g. no mouse response for up to 10 seconds) until it stops. Peter has some ideas about it, but it's a serious enough bug that it forced me to stop using amd64 as my desktop machine (hello, kde!). Hmmm, I have encountered a similar problem on sparc64 once; the reason was that vm_pageout_map_deactivate_pages() calls pmap_remove() for the range from the start to the end of the process's vm_map when a process is swapped out. Start and end are VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS respectively, and on 64-bit architectures, that range is very large (128TB on ia64 if I'm not mistaken), so the iteration in pmap_remove() must be carefully designed to make as large steps as possible to avoid long run times (or to not iterate over the range at all if it becomes too large, which we did on sparc64). It seems that the amd64 version of pmap_remove() will essentially always iterate in 2MB (level 2 page table) steps, regardless of whether there is mapping for the respective level 2 table in the table levels above; that means that in the previously mentioned case, the outer loop will usually run for about 67 million iterations (the resident count guard may not be of much use here if a stack page is left at the very end of the address space). Since there are a few memory accesses needed in each iterations, that may already be the cause of such a delay. You know, this sounds spot-on! Thanks for the tip! -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
At 9:37 AM -0600 6/7/04, Scott Long wrote: Garance A Drosihn wrote: I think you have to officially demote it, with emphasis on the point that demotion is not a terminal condition. Then, if some developer(s) show up and implement all the missing pieces, we can happily announce it back in tier 1. But for now, say that it *IS* demoted. Not that you're advocating that we think about maybe demoting it in the future unless someone offers to start looking into the missing pieces. One thing to note is that whatever platforms get dropped from tier-1 status will have a high probablility of not getting updated with the upcoming binutils/gcc/gdb update that is coming. If that is the case, then you can not say demotion is not a terminal condition. That sounds pretty terminal to me. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2.1: Mutex/Spinlock starvation?
On Monday 07 June 2004 01:35 pm, Ali Niknam wrote: There isn't a timeout. Rather, the lock spins so long as the current owning thread is executing on another CPU. Interesting. Is there a way to 'lock' CPU's so that they always run on 'another' CPU ? Not in userland, no. Unfortunately as we speak the server is down again :( This all makes me wonder wether I should simply go back to 4.10. I decreased the maximum number of apache children to 1400 and the server seems to be barely holding on: last pid: 2483; load averages: 75.77, 28.63, 11.40up 0+00:04:32 19:35:07 1438 processes:2 running, 294 sleeping, 1142 lock CPU states: 6.2% user, 0.0% nice, 62.6% system, 7.5% interrupt, 23.8% idle Mem: 698M Active, 27M Inact, 209M Wired, 440K Cache, 96M Buf, 1068M Free Swap: 512M Total, 512M Free Are there anymore quite stable things to do ? That is except for upping to current, which I frankly feel is too dangerous... Nothing that I can think of off the top of my head. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: testing for substrings in perl
On 7 Jun 2004 at 16:31, Chris Costello wrote:
On Sun, 2003-10-05 at 10:32, Dan Langille wrote:
I think it might just be easier to do a straight comparison of the first N
characters of the two strings where N = length of the directory name.
Any suggestions?
You can do:
if ($string =~ /\/?\Q$expr\E/) {
# ... matches ...
}
\Q and \E are special metaquoting classes in perlre designed
specifically for cases like this.
See 'man perlre' for more gory info.
Who is lagged here Chris? Thanks for the reply though.
FWIW, I suspect this was a FreshPorts-releated issue, and I think I
was trying to solve this problem: is any file touched by this commit
in the ports tree?
foreach $value (@{$Files}) {
my ($action, $filename, $revision, $commit_log_element_id)
= @$value;
print processing $filename\n;
if ($filename =~ m|^/?ports/|) {
$PortTreeCommit = 1;
last;
}
}
--
Dan Langille : http://www.langille.org/
BSDCan - http://www.bsdcan.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Semantics of seteuid(uid) vs. setreuid(-1,uid)
On Sun, Jun 06, 2004, Stefan Eer wrote: Any reason, that there is a difference in semantics between: seteuid(id) vs. setreuid(-1, id)??? The tests performed on the arguments are different (assuming a fixed arg of -1 for ruid) in that seteuid does not support the case of (euid == cr_uid): [...] Is the difference between seteuid() and setreuid() deliberate ? The best rationale I can think of is that setreuid(x, geteuid()) does something useful, whereas seteuid(geteuid()) is a no-op. I think the seteuid() behavior you complain about exists for purely historical reasons. POSIX does not require seteuid(geteuid()) to succeed, but it implicitly allows it as an extension. Solaris and Linux have this extension. The trouble with tweaking the interface is that you always have to ask: what new security holes could this open up in existing software? Hao Chen points out that the failure of seteuid(geteuid()) in FreeBSD is one of many tricky issues with using the set*uid() interface portably. In my (biased) opinion, his Setuid Demystified paper, is well worth reading if you want to untangle this stuff in your mind: http://www.usenix.org/events/sec02/full_papers/chen/chen.pdf ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2.1: Mutex/Spinlock starvation?
On Sat, Jun 05, 2004 at 10:55:31PM +0200, Ali Niknam wrote: I tried this; this helps performance a lot, here are the findings: - under all conditions turning on HTT helps a *lot* (which is logical i think) - under non killing load (killing load = load where server would have crashed without this option) it performs much much better - under killing load it performs a lot better, up until a certain level: - a new killing level: from this point onward basically the same thing happens as before.. Something is happening which should not be at a much more fundamental level. Something is going on to cause everything to block in Giant. That could be some exceptionally-long operation that executes, holding Giant, without andy context switches. In general, this is really what you would call a deadlock, but at least you can recover from it. If the system is totally unresponsive to your input, is it still working from the standpoint of the users on it? Are there strange syslog messages? Can you watch the history of sysctl vm.vmtotal, sysctl vm.zone, and vmstat -m to see if it's a memory starvation issue? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
