Multicores
|
From: Skybuck Flying on 8 Sep 2005 11:33 <robertwessel2(a)yahoo.com> wrote in message news:1126047657.641045.230820(a)g14g2000cwa.googlegroups.com... > > Skybuck Flying wrote: > > <robertwessel2(a)yahoo.com> wrote in message > > news:1125731066.086811.73210(a)z14g2000cwz.googlegroups.com... > > > > > > The number of context switches is not typically reduced in any > > > significant way by going to a dual (or multi-) CPU system. The vast > > > majority of context switches occur because a thread blocks or calls on > > > another thread or context for a service (really the same thing), and > > > those are *not* impacted by the number of CPUs in the system. Context > > > switches due to time slice expirations *can* be reduced by a multiple > > > CPU configuration, but only if the number of threads tends to be close > > > to the number of CPUs. If there are many runnable thread, and the time > > > slice interval does not change, even that can be slower on the dual > > > processor system, since slices will occur after only half the number of > > > instructions. In any event, time slice triggered context switches are > > > *very* rare. At best a few tens to a few hundred per second. > > > > As far as I can tell windows xp doesn't care how many threads are running, > > it will simply give each thread the same ammount of time slice thereby > > lagging the whole system. > > > Windows, like pretty much any other OS, will dole out CPU time in > time-slice increments to threads that run CPU bound, but only rarely > does a thread (in most systems) ever run out a time slice before > blocking on some event (and thus threads are rarely CPU bound). > > > > That's why the number of contex switches doesn't > > increase as the number of threads increase. > > > This is perhaps true for a collection of CPU bound threads, but the > vast majority of threads in a system are (typically) not. > > > > Windows xp makes absolutely no > > attempt to keep the system responsive. To keep the system responsive windows > > xp would need to shorten each time slice and thereby creating more contex > > switches thus leaving less processing power to do anything usefull. > > > Different versions of Windows use different time-slice intervals. And > there are some semi-documented ways that you can change that. Windows > takes considerable effort to keep the system responsive (CPU bound > threads get a priority reduction, foreground applications get a boost, > etc.), but in the presence of multiple CPU bound threads attached to > message queues (which is an application design problem), there's not a > whole lot you can do. > > In short, time slice intervals have only a little to do with system > responsiveness. That's where you are 100% wrong, it has everything to do with system responsiveness. 1. Give an application a higher priority and it's threads will get a longer time slice. 2. Give an application a lower priority and it's threads will get a shorter time slice. That's why 1. lags the system when an application gets to much time. That's why 2. makes an application take very long to complete it's task. Bye, Skybuck.
From: robertwessel2@yahoo.com on 8 Sep 2005 13:01 Skybuck Flying wrote: > > In short, time slice intervals have only a little to do with system > > responsiveness. > > That's where you are 100% wrong, it has everything to do with system > responsiveness. > > 1. Give an application a higher priority and it's threads will get a longer > time slice. > 2. Give an application a lower priority and it's threads will get a shorter > time slice. > > That's why 1. lags the system when an application gets to much time. > That's why 2. makes an application take very long to complete it's task. Of course that's not anything like the way it actually works. If two threads, one high and one low priority, are ready to run, the high priority thread will be dispatched, and time slices have nothing to do with it. In the basic case a runnable high priority thread will prevent all low priority threads from running, period. If two threads of equal priority are both runnable, then, and only then, will time slices come into play to switch between those equal priority threads. That being said, many OSs will apply a dynamic temporary priority boost to lower priority threads if they've not been allowed to run for an extended period of time so that they're not starved of CPU time completely. And there are, of course, more complex schedulers that work not just on thread priority, but take into account system policies that say things like "guarantee at least 15 % of the CPU to job#3." Those often work by watching the run history and adjusting a more traditional priority scheme to meet the goals.
From: Anne & Lynn Wheeler on 8 Sep 2005 14:56 "robertwessel2(a)yahoo.com" <robertwessel2(a)yahoo.com> writes: > Of course that's not anything like the way it actually works. If > two threads, one high and one low priority, are ready to run, the > high priority thread will be dispatched, and time slices have > nothing to do with it. In the basic case a runnable high priority > thread will prevent all low priority threads from running, period. > If two threads of equal priority are both runnable, then, and only > then, will time slices come into play to switch between those equal > priority threads. That being said, many OSs will apply a dynamic > temporary priority boost to lower priority threads if they've not > been allowed to run for an extended period of time so that they're > not starved of CPU time completely. And there are, of course, more > complex schedulers that work not just on thread priority, but take > into account system policies that say things like "guarantee at > least 15 % of the CPU to job#3." Those often work by watching the > run history and adjusting a more traditional priority scheme to meet > the goals. dynamic adaptive resource management that i was doing in the 60s as undergraduate ... used advisory deadlines for dispatching/scheduling (effectively based on size of quanta and the amount of resources the task was getting relative to its target resources). priorities were an aspect of scheduling policy ... default policy was fair share and default priority mechanism adjusted a tasks relative portion of fair share (translated into more or less than overall infrastructure fair share). evolution of that infrastructure were things like partitioning resources among departments and then making individual fair share a portion of the related departments allication ... as opposed to overall total system resources. one of the reasons for doing the change ... was to drastically reduce the pathlength of the then available implementation which was starting to take 10-15 percent of elapsed time ... and used a priority scheme more like that outlined above. previous post http://www.garlic.com/~lynn/2005p.html#21 Multicores the code that i had done as undergraduate was eventually picked up and shipped in the cp67 product. Much of the code was then dropped in the morphing from cp67 to vm370. however it was re-introduced when i did the resource manager for vm370. http://www.garlic.com/~lynn/subtopic.html#fairshare one of the other distinctions of the resource manager was that it was chosen to be the guinea pig for licensed/priced kernel software. with the 6/23/69 unbundling announcement (large part motivated by various litigation activities), there was a switch to start charging/licensing application softwoare ... although kernel software still was free. http://www.garlic.com/~lynn/subtopic.html#unbundle the resource manager got tapped to be priced/licensed kernel software. I got the reward to spend time over period of several months with various business groups working out the changes for pricing for kernel software. the guidelines established with the resource manager was that kernel software not directly involved with hardware support (like device drivers) would still be free ... but other kernel software could be priced separately. this caused a problem for the next base kernel release where they were going to ship SMP support (something else that didn't make the transition from cp67 to vm370 ... even tho all the invention leading up to the compare and swap instruction had been done on cp67). I had includes a bunch of stuff in the resource manager that SMP support needed. However the pricing policy wa that SMP support had to be free (aka hardware support) ... so it was a violation of the policy with you had to buy the resource manager in order for SMP support to work. Eventually they moved stuff required by SMP support out of the licensed/priced resource manager into the base (free) kernel. http://www.garlic.com/~lynn/subtopic.html#smp -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Jeremy Linton on 8 Sep 2005 16:24 >>I have 2 large monitors, an nVidia AGP and an oldish Banshee PCI card >>both run at or near 2k pixels. Dragging almost any large window from >>PCI to AGP, wait precisely 7 secs for the mess to clear up (even plain >>text). The obvious solutions are unpalatable. I don't think multicores >>will help much either. I've used a lot of dual head (or more) windows boxes with diffrent configuration. I've seen similar problems before, and its not windows. It was something in the video card drivers. Updating drivers has cleared up the problem, and in the case of ATI making sure that there isn't more than 1 ATI in the machine seems to help.
From: Skybuck Flying on 8 Sep 2005 19:35
<robertwessel2(a)yahoo.com> wrote in message news:1126195798.401745.156050(a)g49g2000cwa.googlegroups.com... > > Skybuck Flying wrote: > > > In short, time slice intervals have only a little to do with system > > > responsiveness. > > > > That's where you are 100% wrong, it has everything to do with system > > responsiveness. > > > > 1. Give an application a higher priority and it's threads will get a longer > > time slice. > > 2. Give an application a lower priority and it's threads will get a shorter > > time slice. > > > > That's why 1. lags the system when an application gets to much time. > > That's why 2. makes an application take very long to complete it's task. > > > Of course that's not anything like the way it actually works. You are again 100% wrong. What I described above is *exactly* what happens. The threads of the high priority application will get longer time slices. The threads of the low priority application will get shorter time slices. What you describe below is what happens inside a single application. What I described above is what happens when multiple applications are running. See the difference ? Bye, Skybuck. > If two > threads, one high and one low priority, are ready to run, the high > priority thread will be dispatched, and time slices have nothing to do > with it. In the basic case a runnable high priority thread will > prevent all low priority threads from running, period. If two threads > of equal priority are both runnable, then, and only then, will time > slices come into play to switch between those equal priority threads. > That being said, many OSs will apply a dynamic temporary priority boost > to lower priority threads if they've not been allowed to run for an > extended period of time so that they're not starved of CPU time > completely. And there are, of course, more complex schedulers that > work not just on thread priority, but take into account system policies > that say things like "guarantee at least 15 % of the CPU to job#3." > Those often work by watching the run history and adjusting a more > traditional priority scheme to meet the goals. |