Re: ULE Scheduler
At Wed, 13 Jun 2012 17:49:15 +0300, Daniel Kalchev wrote: On 12.06.12 16:08, Momchil Ivanov wrote: So the L2 cache is shared between both cores and hence it's size does not matter at all? If the cache is shared between both cores then it does not matter on which core the process runs, as long as data is in teh case. The cache size is irrelevant. Some CPUs have shared cache between cores, some don't. The ULE scheduler takes this into account, the 4BSD does not. Even if the ULE scheduler takes the CPU topology into consideration, if you only have two cores, it is almost guaranteed that processes will be switched between both, because the OS is running way more than two processes at the same time. Even with more cores... it is not guaranteed an computational process won't be 'bouncing'. Here is an example. Suppose you have an 8 core (or threads) CPU. If you happen to have an modern Ethernet controller, like the Intel 82576 (the igb driver in FreeBSD), then it will use up to 8 interrupt lines, by default routing them each to a different core. Then, if you have heavier network traffic, chances are that at any given moment all 8 interrupts might be fired and all 8 cores switched to service network traffic -- removing your computational process from the running queue. The next time it runs, it might run on any other core, especially if the cache is not shared. Of course, if you have sufficiently large number of CPUs, you can configure your system so that such things do not happen, like by limiting the number of cores the igb driver attaches to, and have some of the cores dedicated to 'only' running an computational task. There is however, very little sense doing so. OK, thank you for the explanation. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
On 12.06.12 16:08, Momchil Ivanov wrote: So the L2 cache is shared between both cores and hence it's size does not matter at all? If the cache is shared between both cores then it does not matter on which core the process runs, as long as data is in teh case. The cache size is irrelevant. Some CPUs have shared cache between cores, some don't. The ULE scheduler takes this into account, the 4BSD does not. Even if the ULE scheduler takes the CPU topology into consideration, if you only have two cores, it is almost guaranteed that processes will be switched between both, because the OS is running way more than two processes at the same time. Even with more cores... it is not guaranteed an computational process won't be 'bouncing'. Here is an example. Suppose you have an 8 core (or threads) CPU. If you happen to have an modern Ethernet controller, like the Intel 82576 (the igb driver in FreeBSD), then it will use up to 8 interrupt lines, by default routing them each to a different core. Then, if you have heavier network traffic, chances are that at any given moment all 8 interrupts might be fired and all 8 cores switched to service network traffic -- removing your computational process from the running queue. The next time it runs, it might run on any other core, especially if the cache is not shared. Of course, if you have sufficiently large number of CPUs, you can configure your system so that such things do not happen, like by limiting the number of cores the igb driver attaches to, and have some of the cores dedicated to 'only' running an computational task. There is however, very little sense doing so. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
On Mon, Jun 11, 2012 at 09:06:26PM +0200, wrote: At Sat, 09 Jun 2012 20:23:44 -0700, Doug Barton wrote: On 06/06/2012 18:16, Doug Barton wrote: On 06/06/2012 18:01, wrote: Is there some remedy? Try the 4BSD scheduler. Did you ever try this? Did it help? I compiled the same kernel with the 4BSD scheduler today and it seems that the processes jump accross cores too. My eye measure with top fells like it's more stable and probably converges faster to a stable state after top jumps accross cores. But in order to talk with numbers, I need to replace top with somethings that dumps the process number and the cpu id continuously in order to get some statistics out of it, otherwise you can just forget all the things that I have written. Is there an easy way to do that and are you interested? Maybe sysutils/atop is useful here? pgptC22WWH1mW.pgp Description: PGP signature
Re: ULE Scheduler
?? ?? momc...@xaxo.eu wrote: I compiled the same kernel with the 4BSD scheduler today and it seems that the processes jump accross cores too. What exactly is the problem that you're seeing? Do you have performance problems? If so, then they're probably *not* caused by processes jumping across cores. Have you read Daniel Kalchev's reply in this thread? He explained very well why that's not a problem usually. Also note that top(1) only shows one snapshot every second or two. It does not show you the hundreds (or thousands) of thread switches that happen every second. In fact, top(1) shows a very misleading picture because it creates the wrong impression that your CPU-bound processes are almost the only ones being scheduled on your cores. Most of the time, people looking at top(1) see problems that don't exist. Another example is the amount of free memory displayed by top that is often misinterpreted. I suggest you just keep the standard scheduler (i.e. ULE). If you don't have a performance problem (i.e. a problem that you can measure by other means than top), then don't try to fix it. Chances are you make things worse. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired. -- Chris Torek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Tue, 12 Jun 2012 11:11:36 +0200 (CEST), Oliver Fromme wrote: ?? ?? momc...@xaxo.eu wrote: I compiled the same kernel with the 4BSD scheduler today and it seems that the processes jump accross cores too. What exactly is the problem that you're seeing? Do you have performance problems? If so, then they're probably *not* caused by processes jumping across cores. When my laptop said bye bye because of the heat I thougt it might be the scheduler, which was a mistake since I got 30 C reduction on full load after cleaning. Therefore, I don't think that there is any problem. I was just curious why both processes are hopping around, because I would naively think that should not happen. Note that I am neither software nor hardware expert, but a mere user of both. I tried the 4BSD scheduler just because Dough asked if I did. For me the question is resolved and I thank all of you for the replies. Have you read Daniel Kalchev's reply in this thread? He explained very well why that's not a problem usually. No, I haven't received that one. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
Momchil Ivanov momc...@xaxo.eu wrote: I was just curious why both processes are hopping around, because I would naively think that should not happen. I'll try to explain ... There are always many more processes and threads being executed beside the two CPU-bound ones that you see at the top of the top(1) display. For example, there are at least 15 threads inside the kernel (see ps -auxww) that are scheduled every now and then. Or look at vmstat -i output to see the interrupt statistics: Several hundred times per second, the interrupt handlers have to be executed. So, what happens is that an interrupt occurs (from a hardware clock, from a hard disk controller, from an input device, or anything else). Then your process is _removed_ from the core on which it is currently executing, and the interrupt handler starts executing. The same can happen on the second core at the same time, because different kernel threads can execute simultaneously (if they don't share resources). Now, if the interrupt handler on one of the two cores is done, your own process has a chance to be scheduled again. In this moment, it does not matter at all on which core it is going to be executed. The only difference is cache contents, but the first-level-caches are usually too small anyway. The ULE scheduler takes a lot of information into account when making the decision, including cache affinity (the 4BSD scheduler doesn't know about that at all). All of that happens several hundreds times per second. You don't have a chance to see it with a tool like top(1). Have you read Daniel Kalchev's reply in this thread? He explained very well why that's not a problem usually. No, I haven't received that one. Ok, I've appended it below. Best regards Oliver begin of quoted text From: Daniel Kalchev dan...@digsys.bg Subject: Re: ULE Scheduler Date: Thu, 7 Jun 2012 12:19:43 +0200 (CEST) Message-ID: 4fd07ea0.8020...@digsys.bg On 07.06.12 11:16, Momchil Ivanov wrote: Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. You never run just two processes on FreeBSD, ever. The kernel too runs multiple threads. However small the CPU usage of the other processes is, they must run from time to time, kicking out at least one of your CPU intensive processes, possibly kicking them out both, as well. When that happens, and they are queued to run again it does not matter much on which core they ran before, because chances are it's cache will be invalidated anyway. Also, different CPUs have different cache affinity. ULE is supposed to be aware of this, while the 4BSD scheduler is not. In any case, on an older single/dual core CPU there is rarely any difference between both schedulers. Differences might appear in modern multi-core CPUs.. Daniel end of quoted text -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Tue, 12 Jun 2012 14:03:10 +0200 (CEST), Oliver Fromme wrote: Momchil Ivanov momc...@xaxo.eu wrote: I was just curious why both processes are hopping around, because I would naively think that should not happen. I'll try to explain ... There are always many more processes and threads being executed beside the two CPU-bound ones that you see at the top of the top(1) display. For example, there are at least 15 threads inside the kernel (see ps -auxww) that are scheduled every now and then. Or look at vmstat -i output to see the interrupt statistics: Several hundred times per second, the interrupt handlers have to be executed. So, what happens is that an interrupt occurs (from a hardware clock, from a hard disk controller, from an input device, or anything else). Then your process is _removed_ from the core on which it is currently executing, and the interrupt handler starts executing. The same can happen on the second core at the same time, because different kernel threads can execute simultaneously (if they don't share resources). Now, if the interrupt handler on one of the two cores is done, your own process has a chance to be scheduled again. In this moment, it does not matter at all on which core it is going to be executed. The only difference is cache contents, but the first-level-caches are usually too small anyway. The ULE scheduler takes a lot of information into account when making the decision, including cache affinity (the 4BSD scheduler doesn't know about that at all). So the L2 cache is shared between both cores and hence it's size does not matter at all? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Sat, 09 Jun 2012 20:23:44 -0700, Doug Barton wrote: On 06/06/2012 18:16, Doug Barton wrote: On 06/06/2012 18:01, Момчил Иванов wrote: Is there some remedy? Try the 4BSD scheduler. Did you ever try this? Did it help? I compiled the same kernel with the 4BSD scheduler today and it seems that the processes jump accross cores too. My eye measure with top fells like it's more stable and probably converges faster to a stable state after top jumps accross cores. But in order to talk with numbers, I need to replace top with somethings that dumps the process number and the cpu id continuously in order to get some statistics out of it, otherwise you can just forget all the things that I have written. Is there an easy way to do that and are you interested? Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
On 06/06/2012 18:16, Doug Barton wrote: On 06/06/2012 18:01, Момчил Иванов wrote: Is there some remedy? Try the 4BSD scheduler. Did you ever try this? Did it help? -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
On Fri, Jun 8, 2012 at 2:29 AM, Momchil Ivanov momc...@xaxo.eu wrote: At Fri, 8 Jun 2012 00:54:15 +0200, Martin Sugioarto wrote: [1 text/plain; UTF-8 (quoted-printable)] Am Thu, 07 Jun 2012 03:01:07 +0200 schrieb Момчил Иванов momc...@xaxo.eu: Is there some remedy? Hi, I remember this series, I've had a T60p and when I compiled world, I placed a fan in front of it to cool it down from 100°C. The difference with T60p was that it simply shut off reaching 101°C. The problem is the hardware, not FreeBSD. T60p and obviously T60, too, was made by some crazy people who had the idea to cool the CPU und the GPU under the same heat sink. The funny thing is that the GPU is running at 70°C all the time, because FreeBSD does not implement voltage regulation for the VGA chipset. The result is that the GPU warms up the CPU to at least 55°C while idle. If you want to have a cooler CPU implement power saving for the Radeon chipset there. Martin [2 signature.asc application/pgp-signature (7bit)] Hi, well, that is not true, I have been using the laptop since more than 4 years without any problems. The thing is that yesterday I had it docked and that seems to raise the idle temperature by about 10°C, so I get docked somewhere about 42°C when doing nothing computationally intensive: hw.acpi.thermal.tz0.temperature: 50.0C hw.acpi.thermal.tz1.temperature: 42.0C dev.cpu.0.temperature: 42.0C dev.cpu.1.temperature: 42.0C So I probably have to shift things around to give the dock a bit more room. However, the dust, the thermal liquid and the screws seem to have contributed to the temperature increase too. The GPU (Nvidia Quadro NVS 140M) might be an issue, nvidia-settings says 58°C (I am not running any fancy graphics) and I've seen it getting over 100-120°C before, when I am doing some opengl stuff. With the latter I mean, that I know how to intentionally kill it. Anyway, I have solved my problem and that seems to not be related to ULE at all. However, it was still surprising for me to find out how ULE schedules computationally intensive tasks. Regards, Momchil My t61p also had overheating problems with fbsd, but never in linux. For me the fan control was somewhat broken: I had to turn off auto-mode and set max myself to get any heavy usage out of it. You might want to check that as well. Regards Andreas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
Am Fri, 8 Jun 2012 08:04:12 +0200 schrieb Andreas Nilsson andrn...@gmail.com: My t61p also had overheating problems with fbsd, but never in linux. For me the fan control was somewhat broken: I had to turn off auto-mode and set max myself to get any heavy usage out of it. You might want to check that as well. Regards Andreas I checked this and my fan was already at full speed (all the time). Linux has got voltage regulation in fglrx as far as I know. As soon as the GPU was using power saving functions on MS-Windows the GPU temperature was far below 50°C. With FreeBSD it was always at 70°C! I don't have the T60p anymore (thanks god). It was an awful laptop. So I cannot give more precise information about this anymore. Martin signature.asc Description: PGP signature
Re: ULE Scheduler
Did anyone ever file a PR for this kind of thing? Adrian On 8 June 2012 10:07, Martin Sugioarto mar...@sugioarto.com wrote: Am Fri, 8 Jun 2012 08:04:12 +0200 schrieb Andreas Nilsson andrn...@gmail.com: My t61p also had overheating problems with fbsd, but never in linux. For me the fan control was somewhat broken: I had to turn off auto-mode and set max myself to get any heavy usage out of it. You might want to check that as well. Regards Andreas I checked this and my fan was already at full speed (all the time). Linux has got voltage regulation in fglrx as far as I know. As soon as the GPU was using power saving functions on MS-Windows the GPU temperature was far below 50°C. With FreeBSD it was always at 70°C! I don't have the T60p anymore (thanks god). It was an awful laptop. So I cannot give more precise information about this anymore. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Thu, 07 Jun 2012 09:12:55 +0700, Erich wrote: Hi, On 07 June 2012 3:01:07 Момчил Иванов wrote: temperature. It was constantly increasing from about 33 C. I took a look at top and saw that both processes were wildly jumping accross the cores, i.e. CPU0 and CPU1. So before reading all the papers about the ULE scheduler and the source code, I would like to as a simple question: is it that stupid? maybe, maybe not. It could be that the difference is minor as the cache for both kernels is in the same chip. I mean, there are just 2 processes running (except of top, X and ... which should be scheduled occasionally) on 2 cores of one physical processor. Why sould each be scheduled on a different core each time? I did cpuset to pin each to a specific core and got to about a constant temperature of 72 C. I am affraid to cpuset -l 0,1 -p ... both of them since I might again get at 100 C. This would be the interesting point? Did it happen because of the dirt or because or the scheduler. Is there some remedy? I think that the only remedy available is the one you applied. Erich I've repeated the same experiment just now, setting both processes on both cores with cpuset. The temperature got to about 72-74 C, so the two small pieces of dirt that came out, the fresh thermal liquid and tightening the screws probably gave me 10 about C on idle (from 53 C down to 45 C) and 30 C on full load. I didn't expect that much... Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
Hi, On 07 June 2012 10:16:07 Momchil Ivanov wrote: At Thu, 07 Jun 2012 09:12:55 +0700, Erich wrote: I've repeated the same experiment just now, setting both processes on both cores with cpuset. The temperature got to about 72-74 C, so the two small pieces of dirt that came out, the fresh thermal liquid and tightening the screws probably gave me 10 about C on idle (from 53 C down to 45 C) and 30 C on full load. I didn't expect that much... this sounds very normal to me. I clean my desktop every two months of operation. A drop of 10K is normal just for blowing the heat sink. The best design of a notebook I every have seen was my old Fujitsu. I used it from 2004 until the beginning of the year without any cleaning and any problems with dirt. After it was dead I disassembled it and did not find any dust blocking anything. Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. This switch might always help. I did some tests more than a year ago. I left the BSD Scheduler then on the single core Fujitsu notebook mentioned above but used the new one my desktop machine. It will also depend on the software you are running. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
On 07.06.12 11:16, Momchil Ivanov wrote: Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. You never run just two processes on FreeBSD, ever. The kernel too runs multiple threads. However small the CPU usage of the other processes is, they must run from time to time, kicking out at least one of your CPU intensive processes, possibly kicking them out both, as well. When that happens, and they are queued to run again it does not matter much on which core they ran before, because chances are it's cache will be invalidated anyway. Also, different CPUs have different cache affinity. ULE is supposed to be aware of this, while the 4BSD scheduler is not. In any case, on an older single/dual core CPU there is rarely any difference between both schedulers. Differences might appear in modern multi-core CPUs.. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
Am Thu, 07 Jun 2012 03:01:07 +0200 schrieb Момчил Иванов momc...@xaxo.eu: Is there some remedy? Hi, I remember this series, I've had a T60p and when I compiled world, I placed a fan in front of it to cool it down from 100°C. The difference with T60p was that it simply shut off reaching 101°C. The problem is the hardware, not FreeBSD. T60p and obviously T60, too, was made by some crazy people who had the idea to cool the CPU und the GPU under the same heat sink. The funny thing is that the GPU is running at 70°C all the time, because FreeBSD does not implement voltage regulation for the VGA chipset. The result is that the GPU warms up the CPU to at least 55°C while idle. If you want to have a cooler CPU implement power saving for the Radeon chipset there. Martin signature.asc Description: PGP signature
Re: ULE Scheduler
At Fri, 8 Jun 2012 00:54:15 +0200, Martin Sugioarto wrote: [1 text/plain; UTF-8 (quoted-printable)] Am Thu, 07 Jun 2012 03:01:07 +0200 schrieb Момчил Иванов momc...@xaxo.eu: Is there some remedy? Hi, I remember this series, I've had a T60p and when I compiled world, I placed a fan in front of it to cool it down from 100°C. The difference with T60p was that it simply shut off reaching 101°C. The problem is the hardware, not FreeBSD. T60p and obviously T60, too, was made by some crazy people who had the idea to cool the CPU und the GPU under the same heat sink. The funny thing is that the GPU is running at 70°C all the time, because FreeBSD does not implement voltage regulation for the VGA chipset. The result is that the GPU warms up the CPU to at least 55°C while idle. If you want to have a cooler CPU implement power saving for the Radeon chipset there. Martin [2 signature.asc application/pgp-signature (7bit)] Hi, well, that is not true, I have been using the laptop since more than 4 years without any problems. The thing is that yesterday I had it docked and that seems to raise the idle temperature by about 10°C, so I get docked somewhere about 42°C when doing nothing computationally intensive: hw.acpi.thermal.tz0.temperature: 50.0C hw.acpi.thermal.tz1.temperature: 42.0C dev.cpu.0.temperature: 42.0C dev.cpu.1.temperature: 42.0C So I probably have to shift things around to give the dock a bit more room. However, the dust, the thermal liquid and the screws seem to have contributed to the temperature increase too. The GPU (Nvidia Quadro NVS 140M) might be an issue, nvidia-settings says 58°C (I am not running any fancy graphics) and I've seen it getting over 100-120°C before, when I am doing some opengl stuff. With the latter I mean, that I know how to intentionally kill it. Anyway, I have solved my problem and that seems to not be related to ULE at all. However, it was still surprising for me to find out how ULE schedules computationally intensive tasks. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ULE Scheduler
Hi, today I had a really strange experience with my laptop. I ran 2 lisp processes each consuming 100% CPU (i.e. in top, 100% CPU means one full core), since I have 2 cores, it means full processor load. I was moreover running Emacs and Opera, but that is more or less irrelevant since they consume negligible amount of CPU time. At some point my Xorg died and I was dropped in the terminal and the first thought through my mind was that my laptop just said goodbye, it was nice meeting you after 4+ years. A second later I saw: Jun 7 01:00:06 t61 kernel: acpi_tz1: WARNING - current temperature (100.1C) exceeds safe limits which was a sign of relief: oh, maybe the fan got busted So I took a screw driver and disassembled my Lenovo T61. Cleaning all the dust and putting a fresh amount of thermal fluid (did it 1 year ago), I booted again and started both processes again and took a look at the temperature. It was constantly increasing from about 33 C. I took a look at top and saw that both processes were wildly jumping accross the cores, i.e. CPU0 and CPU1. So before reading all the papers about the ULE scheduler and the source code, I would like to as a simple question: is it that stupid? I mean, there are just 2 processes running (except of top, X and ... which should be scheduled occasionally) on 2 cores of one physical processor. Why sould each be scheduled on a different core each time? I did cpuset to pin each to a specific core and got to about a constant temperature of 72 C. I am affraid to cpuset -l 0,1 -p ... both of them since I might again get at 100 C. Is there some remedy? Please CC me, since I am not subscribed to the list. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
On 06/06/2012 18:01, Момчил Иванов wrote: Is there some remedy? Try the 4BSD scheduler. -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
Hi, On 07 June 2012 3:01:07 Момчил Иванов wrote: temperature. It was constantly increasing from about 33 C. I took a look at top and saw that both processes were wildly jumping accross the cores, i.e. CPU0 and CPU1. So before reading all the papers about the ULE scheduler and the source code, I would like to as a simple question: is it that stupid? maybe, maybe not. It could be that the difference is minor as the cache for both kernels is in the same chip. I mean, there are just 2 processes running (except of top, X and ... which should be scheduled occasionally) on 2 cores of one physical processor. Why sould each be scheduled on a different core each time? I did cpuset to pin each to a specific core and got to about a constant temperature of 72 C. I am affraid to cpuset -l 0,1 -p ... both of them since I might again get at 100 C. This would be the interesting point? Did it happen because of the dirt or because or the scheduler. Is there some remedy? I think that the only remedy available is the one you applied. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: About nice(1), renice(8) and ULE scheduler
In fact nice is a very simple program. It only changes the priority value of a process in a POSIX-compliant way. There is no need to change or adapt it; it still works fine in the SMP world and with new schedulers. It's up to the scheduler to interpret and handle the priority values of processes. In other words: The nice(1) tool only attaches a number to a process, nothing more. Only the scheduler knows what that number means. So there's no need to change nice(1). Great. So, the key is the scheduler; it makes sense. By the way, the source code of nice(1) is almost trivial. Basically it just calls the setpriority(2) and execve(2) syscalls. 99% of the source file consists of the BSD license test, arguments parsing and C syntax overhead. Thanks for aclaration. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: About nice(1), renice(8) and ULE scheduler
Jordi Espasa Clofent jespa...@minibofh.org wrote: I've realized that the nice(1) code hasn't been modified for a long time (last code change seems from 4 years ago according the sources). ¿Is the nice(1) behaviour the expected? I mean, ¿Has been the ULE scheduler adapted to nice(1) command or not? nice(1) is a very old command based on old concepts and created in times when SMP didn't exist. So ¿it works correctly when a modern an re-designed scheduler as ULE is used? In fact nice is a very simple program. It only changes the priority value of a process in a POSIX-compliant way. There is no need to change or adapt it; it still works fine in the SMP world and with new schedulers. It's up to the scheduler to interpret and handle the priority values of processes. In other words: The nice(1) tool only attaches a number to a process, nothing more. Only the scheduler knows what that number means. So there's no need to change nice(1). By the way, the source code of nice(1) is almost trivial. Basically it just calls the setpriority(2) and execve(2) syscalls. 99% of the source file consists of the BSD license test, arguments parsing and C syntax overhead. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
About nice(1), renice(8) and ULE scheduler
HI all, I've realized that the nice(1) code hasn't been modified for a long time (last code change seems from 4 years ago according the sources). ¿Is the nice(1) behaviour the expected? I mean, ¿Has been the ULE scheduler adapted to nice(1) command or not? nice(1) is a very old command based on old concepts and created in times when SMP didn't exist. So ¿it works correctly when a modern an re-designed scheduler as ULE is used? Maybe I have to read again this paper: http://www.usenix.org/event/bsdcon03/tech/full_papers/roberson/roberson.pdf -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ule scheduler
I see this is the standard recommendation for those of us using SMP. I am wondering how far away we are from that becoming standard, since on even amd64, I see the older scheduler is still in place? Brian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ule scheduler
On Fri, Apr 18, 2008 at 11:35 PM, Brian [EMAIL PROTECTED] wrote: I see this is the standard recommendation for those of us using SMP. I am wondering how far away we are from that becoming standard, since on even amd64, I see the older scheduler is still in place? I believe the current plan is to have ULE be the default scheduler in 7.1-RELEASE. I've been using it since 7.0-PRERELEASE and have had no problems with it, though it is slower than 4BSD for some very specific workloads (ffmpeg with multiple threads). Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ule scheduler
Brian wrote: I see this is the standard recommendation for those of us using SMP. I am wondering how far away we are from that becoming standard, since on even amd64, I see the older scheduler is still in place? It *is* the default scheduler for RELENG_7 and -HEAD for most architectures. Cheers, -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Mar 14, 2007, at 1:55, Kris Kennaway wrote: This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. This might be standard dogma, but it also appears not to be true: http://people.freebsd.org/~kris/scaling/mysql.html Interesting. Results I have seen using a 16 CPU SGI Altex(?) showed an almost linear rise for postgres while mysql topped off after about 4 threads. Sorry, don't have the URL at hand (I probably still have it in my work mail). Now this may well have been a version before 5.0.33. I'm not sure what OS was used either, I suppose it was either Irix or Linux. Now I am curious whether the same performance drop on Linux would occur with a postgres benchmark. It probably will, but if not it seems like there's a problem in the way that mysql and linux interact. -- Alban Hertroys If you can't see the forest through the trees, cut the trees and you'll see there is no forest !DSPAM:74,45f7b2c29417620521737! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Mar 14, 2007, at 1:55, Steven Hartland wrote: Alban Hertroys wrote: Sorry, couldn't resist... Being a troll? I don't troll, I'm not like that. I have a problem with how mysql often gets falsely marketed as the fastest database. The subject just pushed the right buttons, sorry about that. Apparently I was vaguely aware of that, or I wouldn't have written that. This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. You seem to have been paying no attention at all to any of the mysql performance benchmarks and optimisation efforts that have being going on recently. I keep track of this ML, this was the first time I've seen the topic come up. If this started somewhere else, then sorry, didn't know about it. I have to admit I was confused about the purpose of the benchmark. I am so used to seeing (usually bad) comparison benchmarks between mysql and postgres that I mistook this for one. That's probably due to me being a postgresql mailing list regular. Not to say that PostgreSQL is the ultimate benchmark instead of mysql, just a better one. Of course they both have their uses, but IMO mysql is loosing terrain fast. Any benchmark which looks to closely emulate real life work is valid, just be because you dont use or like a particular product doesnt make it any less suitable for testing / benchmarking. I'm sure if you took a survey of how many people are using mysql vs PostgreSQL it would show that the former is much more popular DB. No this doesnt make it better but it does make it a more suitable candidate for performance work as the benefits will benefit more people and more systems. Well, that depends on what you're trying to benchmark of course. It keeps amazing me that people choose a product based on how many people use it, instead of how well it works. That goes for mysql vs postgresql as much as for linux vs freebsd. In that way benchmarks like these are useful; it shows that freebsd outperforms linux if you use mysql. It shows that what most people chose is not necessarily the best choice. What I would have liked to see was a graph showing that postgresql on FreeBSD performs both better than MySQL on either platform and better than postgresql on linux (all of which are quite theoretical at this point). Combined into a well written and well argumented article (that is easy to stumble upon preferably), that may just help a little to get people off that ridiculous idea. It also has a known bottleneck to its performance on FreeBSD see earlier comments in other threads by Kris on this which clearly limits any benefit gained from using it as a benchmark. This is unfortunate, and now you mention it I do have a vague recollection of a problem discussion. I'll have to read up on that once I have the time to, and I hope to be able to cross-reference that to the pg-general ML. In real life situations, I usually find that a database problem can often be rewritten into a more optimal design once you move from mysql to postgresql. I use both, although I vastly prefer postgresql. Where you hit a brick wall with mysql, you can usually move on in postgresql by putting data into materialised views, using smarter subqueries, stored procedures, triggers, contrib packages like ltree, etc. So, even though there is apparently a bottleneck with it on FreeBSD (not too severe, I hope), the end result may still be better than when using mysql. I realise this is starting to get off topic, I suggest replies should focus on the first half of my reply. -- Alban Hertroys If you can't see the forest through the trees, cut the trees and you'll see there is no forest !DSPAM:74,45f847759413227012565! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
You can view my benchmark here: https://manuelmartini.it/bench/mysql/ m. signature.asc Description: PGP signature
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
Martin wrote: You can view my benchmark here: https://manuelmartini.it/bench/mysql/ Interesting results. The performance improvements talked about at http://jeffr-tech.livejournal.com/6268.html#cutid1 are not yet included in 7-current so the results might improve :) signature.asc Description: OpenPGP digital signature
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Tue, Mar 13, 2007 at 03:42:06PM -0400, Craig Rodrigues wrote: On Tue, Mar 13, 2007 at 03:47:29PM +0100, Martin wrote: You can view my benchmark here: https://manuelmartini.it/bench/mysql/ Can you add links your kernel config file for each configuration you tested? It looks like your 6.2 configuration does not have WITNESS enabled, but your 7.0 configuration does. Also some more discussion would be useful, e.g. you appear to be testing on different machines so the most important thing to understand is how, or whether, the hardware differs. You do link to the dmesgs, but it's hard to process this into a summary form whereas you presumably know the details. I am also unfamiliar with the benchmark itself, can you give me a pointer to the software? If it is doing disk I/O then you may be mostly measuring the speed of your disks, which is why the previous paragraph is so important to understand. Kris P.S. Also, making this available by http instead of https would be great, your SSL certificates are expired, unsigned and misconfigured so you have to go through 3 dialogue boxes to load the page. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
Il giorno Tue, 13 Mar 2007 15:42:06 -0400 Craig Rodrigues [EMAIL PROTECTED] ha scritto: On Tue, Mar 13, 2007 at 03:47:29PM +0100, Martin wrote: You can view my benchmark here: https://manuelmartini.it/bench/mysql/ Can you add links your kernel config file for each configuration you tested? It looks like your 6.2 configuration does not have WITNESS enabled, but your 7.0 configuration does. I use GENERIC kernel file for 6.2 and GENERIC on 7 and I removed WITNESS signature.asc Description: PGP signature
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
Il giorno Tue, 13 Mar 2007 15:57:57 -0400 Kris Kennaway [EMAIL PROTECTED] ha scritto: On Tue, Mar 13, 2007 at 03:42:06PM -0400, Craig Rodrigues wrote: On Tue, Mar 13, 2007 at 03:47:29PM +0100, Martin wrote: You can view my benchmark here: https://manuelmartini.it/bench/mysql/ Can you add links your kernel config file for each configuration you tested? It looks like your 6.2 configuration does not have WITNESS enabled, but your 7.0 configuration does. Also some more discussion would be useful, e.g. you appear to be testing on different machines so the most important thing to understand is how, or whether, the hardware differs. You do link to the dmesgs, but it's hard to process this into a summary form whereas you presumably know the details. I use the same hw (3 dell 1435 server) I am also unfamiliar with the benchmark itself, can you give me a pointer to the software? I used sql-bench /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql-bench/ (at this time) the default Makefile of port have --without-bench options so u need to make manually If it is doing disk I/O then you may be mostly measuring the speed of your disks, which is why the previous paragraph is so important to understand. the disk was the same of 3 test signature.asc Description: PGP signature
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Tue, Mar 13, 2007 at 09:13:56PM +0100, Martin wrote: Il giorno Tue, 13 Mar 2007 15:42:06 -0400 Craig Rodrigues [EMAIL PROTECTED] ha scritto: On Tue, Mar 13, 2007 at 03:47:29PM +0100, Martin wrote: You can view my benchmark here: https://manuelmartini.it/bench/mysql/ Can you add links your kernel config file for each configuration you tested? It looks like your 6.2 configuration does not have WITNESS enabled, but your 7.0 configuration does. I use GENERIC kernel file for 6.2 and GENERIC on 7 and I removed WITNESS How about INVARIANTS? This has a 10-20% cost depending on workload. Kris pgps2qZXwgb28.pgp Description: PGP signature
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Tue, Mar 13, 2007 at 09:19:08PM +0100, Martin wrote: Also some more discussion would be useful, e.g. you appear to be testing on different machines so the most important thing to understand is how, or whether, the hardware differs. You do link to the dmesgs, but it's hard to process this into a summary form whereas you presumably know the details. I use the same hw (3 dell 1435 server) I am also unfamiliar with the benchmark itself, can you give me a pointer to the software? I used sql-bench /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql-bench/ (at this time) the default Makefile of port have --without-bench options so u need to make manually Hmm. This seems to be a single-user test, so while it's presumably testing some relevant basic ingredients of database performance it's probably not a realistic measure of server performance. i.e. if you really only have a maximum of one client accessing your database then your 4-core system is being more than 75% wasted :) If it is doing disk I/O then you may be mostly measuring the speed of your disks, which is why the previous paragraph is so important to understand. the disk was the same of 3 test OK, cool. The difference between i386 and amd64 is actually kind of surprising. I would have expected amd64 to be slower. One thing that is missing is an estimate of standard deviation of the data points: some benchmarks have very high variance, meaning the numbers vary a lot between runs; this makes direct comparison more difficult without statistical work. In FreeBSD the /usr/src/tools/tools/ministat utility is excellent for this purpose. Kris pgpprt9gQ9Ai2.pgp Description: PGP signature
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Tue, Mar 13, 2007 at 09:13:56PM +0100, Martin wrote: I use GENERIC kernel file for 6.2 and GENERIC on 7 and I removed WITNESS You did not remove WITNESS in all your configs. I see this message: WARNING: WITNESS option enabled, expect reduced performance. in the dmesg output of two of your tests. Can you just publish the exact kernel config in the results table that you used, to make it easier to figure out your exact configuration, instead of guessing? -- Craig Rodrigues [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Mar 13, 2007, at 22:45, Kris Kennaway wrote: I used sql-bench /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql-bench/ (at this time) the default Makefile of port have --without-bench options so u need to make manually Hmm. This seems to be a single-user test, so while it's presumably testing some relevant basic ingredients of database performance it's probably not a realistic measure of server performance. i.e. if you really only have a maximum of one client accessing your database then your 4-core system is being more than 75% wasted :) Sorry, couldn't resist... This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. I've had my doubts about this benchmark from the beginning of this thread, I don't see the point of benchmarks using mysql - especially if it's not even clear whether myIsam or Innodb was used. If this benchmark means anything, I'm sure there are benchmarks that better suit the purpose (with the exception of benchmarking mysql performance for a single connection). What are we actually trying to benchmark here? In my experience mysql as a database accepts invalid data, doesn't comply to the SQL standards much and isn't very fast at real-life database queries - among other things. It doesn't compare[1] to a tuned PostgreSQL database, which I think is a considerably more interesting benchmark. And of course that would include multiple simultaneous connections. Not to say that PostgreSQL is the ultimate benchmark instead of mysql, just a better one. Of course they both have their uses, but IMO mysql is loosing terrain fast. [1] I really mean it doesn't compare. PostgreSQL provides more (and IMHO better) features, and can be faster under the right circumstances (usually complex queries or concurrent writes). It also scales almost linearly to the number of cpu's, provided there are enough simultaneous connections. -- Alban Hertroys Priest to alien: We want to know, is there a higher being?. Alien: Well, actually that's why we're here, we're sheer out of virgins. !DSPAM:74,45f741509413780612645! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Wed, Mar 14, 2007 at 01:27:22AM +0100, Alban Hertroys wrote: On Mar 13, 2007, at 22:45, Kris Kennaway wrote: I used sql-bench /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql-bench/ (at this time) the default Makefile of port have --without-bench options so u need to make manually Hmm. This seems to be a single-user test, so while it's presumably testing some relevant basic ingredients of database performance it's probably not a realistic measure of server performance. i.e. if you really only have a maximum of one client accessing your database then your 4-core system is being more than 75% wasted :) Sorry, couldn't resist... This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. This might be standard dogma, but it also appears not to be true: http://people.freebsd.org/~kris/scaling/mysql.html It doesn't compare[1] to a tuned PostgreSQL database, which I think is a considerably more interesting benchmark. And of course that would include multiple simultaneous connections. On the same test postgresql is indeed faster, I haven't finished benchmarking it yet though. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
Alban Hertroys wrote: Sorry, couldn't resist... Being a troll? This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. You seem to have been paying no attention at all to any of the mysql performance benchmarks and optimisation efforts that have being going on recently. Not to say that PostgreSQL is the ultimate benchmark instead of mysql, just a better one. Of course they both have their uses, but IMO mysql is loosing terrain fast. Any benchmark which looks to closely emulate real life work is valid, just be because you dont use or like a particular product doesnt make it any less suitable for testing / benchmarking. I'm sure if you took a survey of how many people are using mysql vs PostgreSQL it would show that the former is much more popular DB. No this doesnt make it better but it does make it a more suitable candidate for performance work as the benefits will benefit more people and more systems. Obviously this doesnt mean that optimisations for DB X wont benefit DB Y, or other apps for that matter, as its likely they will. [1] I really mean it doesn't compare. PostgreSQL provides more (and IMHO better) features, and can be faster under the right circumstances (usually complex queries or concurrent writes). It also scales almost linearly to the number of cpu's, provided there are enough simultaneous connections. It also has a known bottleneck to its performance on FreeBSD see earlier comments in other threads by Kris on this which clearly limits any benefit gained from using it as a benchmark. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE-scheduler helped (Re: new em-driver still broken)
On Tuesday 31 October 2006 20:41, Jack Vogel wrote: = I still think it looks like some kind of scheduler issue going on = here, so maybe this is something to check. Ok. First I tried to cvs the sys/dev/em back to 6.1 -- the new kernel had the same problems... Then I tried to change the 'PCI latency timer' in the BIOS -- from the minimum of 32 to the maximum of 360. Same problems. Then, finally, I decided to give the ULE-scheduler a try -- and things seem to work just fine (with polling enabled on the interface)... The dump has completed -- in 7 hours or so... Could this (failure of the BSD44 scheduler) be due to my using slightly different CPUs (Opteron 244 in the first slot and 246 in the second)? I thought, BIOS/motherboard take care to downgrade the second one to match -- according to the dmesg.boot, both processors are identified as: CPU: AMD Opteron(tm) Processor 244 (1800.01-MHz K8-class CPU) But if the scheduler looks at some CPU-local register, it may, in some cases, still think, it is running on 246? To summarize, unless someone else continues to see em-related problems, the current driver is fine, I guess... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE scheduler freezes kernel
On Thu, Mar 17, 2005 at 10:14:50PM +0100, Rene Ladan wrote:
Hi,
I was trying the ULE scheduler again on my single i686 5.4PRE laptop,
but it causes the kernel to freeze after some time (=30 minutes): the
kernel does not even respond to opening/closing the lid when booting
verbose (normally it displays acpi_lid0: Lid {opened|closed}).
Having some disk activity (e.g. portupgrade) seems to catalyze this
behaviour. Only a full power reset gets the laptop running again. I do
[...]
This seems to be solved with RELENG_6 :
% uname -v
FreeBSD 6.0-BETA2 #5: Thu Aug 11 16:50:36 CEST 2005
root@:/usr/obj/usr/src/sys/RENE
% sysctl kern.sched.name
kern.sched.name: ule
% uptime
3:35pm up 3 days, 1:17, 6 users, load averages: 1,00 1,02 1,00
And it even survived an OpenOffice portupgrade. :)
Regards,
Rene
--
GPG fingerprint = 5FFA 3959 3377 C697 8428 24D0 BF3E F4A9 AE33 5DCC
It won't fit on the line.
-- me, 2001
pgpx3g0fx4mnm.pgp
Description: PGP signature
ULE scheduler freezes kernel
Hi,
I was trying the ULE scheduler again on my single i686 5.4PRE laptop,
but it causes the kernel to freeze after some time (=30 minutes): the
kernel does not even respond to opening/closing the lid when booting
verbose (normally it displays acpi_lid0: Lid {opened|closed}).
Having some disk activity (e.g. portupgrade) seems to catalyze this
behaviour. Only a full power reset gets the laptop running again. I do
not have this problem with the 4BSD scheduler.
Sources are from March 16, 23:10 UTC.
Full details are available using anonymous ftp at
ftp://82.168.140.74/pub/ {conf|log}
Regards,
Rene
--
It won't fit on the line.
-- me, 2001
pgp1e980OYJvb.pgp
Description: PGP signature
ULE scheduler broken and not documented
Hello to all, I'm runinng RELENG_5 and I noticed that ULE scheduler is broken. Shouldn't this be documented in UPDATING? Thanks very much, Nuno Teixeira -- SDF Public Access UNIX System - http://sdf.lonestar.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE scheduler broken and not documented
On Wed, Dec 08, 2004 at 10:21:02PM +, Nuno Teixeira wrote: Hello to all, I'm runinng RELENG_5 and I noticed that ULE scheduler is broken. Shouldn't this be documented in UPDATING? Yes. I thought it was, but you are correct in asserting that it isn't. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgp4V2nNOidQ9.pgp Description: PGP signature
Re: ULE scheduler broken and not documented
On Wednesday 08 December 2004 04:21 pm, Nuno Teixeira wrote: Hello to all, I'm runinng RELENG_5 and I noticed that ULE scheduler is broken. Shouldn't this be documented in UPDATING? Thanks very much, Nuno Teixeira It's documented in errata: (1 Nov 2004) The ULE scheduler described in the release notes has been completely disabled to discourage its use because it has stability problems. Don -- Donald J. O'Neill [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE Scheduler available in 5.3-RELEASE?
Can you describe advantages of using SCHED_ULE on UP? or just link or something. Michael Nottebrock wrote: On Thursday, 11. November 2004 16:42, Ronald Klop wrote: On Thu, 11 Nov 2004 09:29:08 -0600, Thomas T. Veldhouse [EMAIL PROTECTED] wrote: I just read in the release notes that 5.3-RELEASE has the new ULE scheduler available, but that 4BSD is the default scheduler. I thought I read messages in freebsd-current indicating that the option to use ULE was completely removed from the 5.3 or even the RELENG_5 branch? So, is ULE really available? Not in RELENG_5 and not in RELENG_5_3. There are issues with it. If it is fixed it will come back. See this line in /usr/src/sys/kern/sched_ule.c: #error The SCHED_ULE scheduler is broken. Please use SCHED_4BSD ... which of course you can just patch out. :) I'm still using ULE on my (UP) machine, works fine for me. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE Scheduler available in 5.3-RELEASE?
I just read in the release notes that 5.3-RELEASE has the new ULE scheduler available, but that 4BSD is the default scheduler. I thought I read messages in freebsd-current indicating that the option to use ULE was completely removed from the 5.3 or even the RELENG_5 branch? So, is ULE really available? -- Thomas T. Veldhouse Key Fingerprint: 07C7 BF05 4176 F50B A083 4542 0118 1315 761F D300 Spammers please contact me at [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: ULE Scheduler available in 5.3-RELEASE?
On Thu, Nov 11, 2004 at 09:29:08AM -0600, Thomas T. Veldhouse wrote: I just read in the release notes that 5.3-RELEASE has the new ULE scheduler available, but that 4BSD is the default scheduler. I thought I read messages in freebsd-current indicating that the option to use ULE was completely removed from the 5.3 or even the RELENG_5 branch? So, is ULE really available? ULE is not available in 5.3 or RELENG_5 due to problems that were unfixed at the time of the release. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpHDg42IWgeI.pgp Description: PGP signature
Re: ULE Scheduler available in 5.3-RELEASE?
Brooks Davis wrote: On Thu, Nov 11, 2004 at 09:29:08AM -0600, Thomas T. Veldhouse wrote: I just read in the release notes that 5.3-RELEASE has the new ULE scheduler available, but that 4BSD is the default scheduler. I thought I read messages in freebsd-current indicating that the option to use ULE was completely removed from the 5.3 or even the RELENG_5 branch? So, is ULE really available? ULE is not available in 5.3 or RELENG_5 due to problems that were unfixed at the time of the release. -- Brooks Perhaps the release notes should be updated? Here is a quote (http://www.freebsd.org/releases/5.3R/relnotes-i386.html#NEW): The ULE scheduler has been added as an additional scheduler. Note that the conventional one, which is called 4BSD, is still used as the default scheduler in the GENERIC kernel. For the average user, interactivity is reported to be better in many cases. This means less ``skipping'' and ``jerking'' in interactive applications while the machine is very busy. This will not prevent problems due to overloaded disk subsystems, but it does help with overloaded CPUs. On SMP machines, ULE has per-CPU run queues which allow for CPU affinity, CPU binding, and advanced HyperThreading support, as well as providing a framework for more optimizations in the future. As fine-grained kernel locking continues, the scheduler will be able to make more efficient use of the available parallel resources. Thanks in advance. -- Thomas T. Veldhouse Key Fingerprint: 07C7 BF05 4176 F50B A083 4542 0118 1315 761F D300 Spammers please contact me at [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: ULE Scheduler available in 5.3-RELEASE?
On Thu, 11 Nov 2004 09:29:08 -0600, Thomas T. Veldhouse [EMAIL PROTECTED] wrote: I just read in the release notes that 5.3-RELEASE has the new ULE scheduler available, but that 4BSD is the default scheduler. I thought I read messages in freebsd-current indicating that the option to use ULE was completely removed from the 5.3 or even the RELENG_5 branch? So, is ULE really available? Not in RELENG_5 and not in RELENG_5_3. There are issues with it. If it is fixed it will come back. See this line in /usr/src/sys/kern/sched_ule.c: #error The SCHED_ULE scheduler is broken. Please use SCHED_4BSD Ronald. -- Ronald Klop, Amsterdam, The Netherlands ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE Scheduler available in 5.3-RELEASE?
Brooks Davis wrote: On Thu, Nov 11, 2004 at 09:29:08AM -0600, Thomas T. Veldhouse wrote: I just read in the release notes that 5.3-RELEASE has the new ULE scheduler available, but that 4BSD is the default scheduler. I thought I read messages in freebsd-current indicating that the option to use ULE was completely removed from the 5.3 or even the RELENG_5 branch? So, is ULE really available? ULE is not available in 5.3 or RELENG_5 due to problems that were unfixed at the time of the release. -- Brooks Perhaps the release notes should be updated? Here is a quote (http://www.freebsd.org/releases/5.3R/relnotes-i386.html#NEW): The ULE scheduler has been added as an additional scheduler. Note that the conventional one, which is called 4BSD, is still used as the default scheduler in the GENERIC kernel. For the average user, interactivity is reported to be better in many cases. This means less ``skipping'' and ``jerking'' in interactive applications while the machine is very busy. This will not prevent problems due to overloaded disk subsystems, but it does help with overloaded CPUs. On SMP machines, ULE has per-CPU run queues which allow for CPU affinity, CPU binding, and advanced HyperThreading support, as well as providing a framework for more optimizations in the future. As fine-grained kernel locking continues, the scheduler will be able to make more efficient use of the available parallel resources. Thanks in advance. -- Thomas T. Veldhouse Key Fingerprint: 07C7 BF05 4176 F50B A083 4542 0118 1315 761F D300 Spammers please contact me at [EMAIL PROTECTED] I beleive the errata document takes precedance over the release notes. In which case... (http://www.freebsd.org/releases/5.3R/errata.html#OPEN-ISSUES) (1 Nov 2004) The ULE scheduler described in the release notes has been completely disabled to discourage its use because it has stability problems. -- Mark Magiera ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE Scheduler available in 5.3-RELEASE?
On Thursday, 11. November 2004 16:42, Ronald Klop wrote: On Thu, 11 Nov 2004 09:29:08 -0600, Thomas T. Veldhouse [EMAIL PROTECTED] wrote: I just read in the release notes that 5.3-RELEASE has the new ULE scheduler available, but that 4BSD is the default scheduler. I thought I read messages in freebsd-current indicating that the option to use ULE was completely removed from the 5.3 or even the RELENG_5 branch? So, is ULE really available? Not in RELENG_5 and not in RELENG_5_3. There are issues with it. If it is fixed it will come back. See this line in /usr/src/sys/kern/sched_ule.c: #error The SCHED_ULE scheduler is broken. Please use SCHED_4BSD ... which of course you can just patch out. :) I'm still using ULE on my (UP) machine, works fine for me. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp5FXsD7ht0V.pgp Description: PGP signature
