Messages in this thread |  | | From | "Chris Swiedler" <> | Subject | RE: [RFC] Implementing temporal affinity | Date | Mon, 28 Aug 2000 10:20:37 -0400 |
| |
> On Fri, 25 Aug 2000, Chris Swiedler wrote: > > > > > B only ran for 15 cycles, and therefore it ISN'T the time-affinity > > > process. > > > > > > But it is. It's run long enough to load the CPU cache with it's own > > > instructions and data. Since you are trying to preserve the CPU cache, > > > you want it to run again instead of something else. Right? > > > > We would only set last_cpu IF the process has run for N cycles, > > where N is enough to fill the CPU cache. If 15 cycles loads the > > cache, then N=15. So in that case, B's last_cpu would be set, > > and it would be tied to that processor. The actual value is > > tunable, and depends largely on the size of the L2 cache. > > That doesn't make much sense. If a process gave up the CPU > after very few cycles (because vi was ready echoing back > the key you typed), it has everything it needed to do that > in the cache...
Is this true? I was under the impression that it took a certain number of cycles to fill up the CPU cache. If a process executes 1 instruction, is the cache going to be full of its data? How about 10, 20, 300? I was thinking that there was some number of cycles N, and processes which executed for less than N wouldn't have a signifigant amount of information in the cache.
I'm reasonably certain that (even if it would work) the patch wouldn't be worth the extra instructions in schedule(), but that's a different story...
chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |