1

I disable the cache by setting the CD bit of CR0 for my intel machine. I used the code described in my previous post

I also use the smp_call_function() function to set all CPU's CR0.

The problem is:

After I set all CPU's CR0's CD bit, the machine becomes extremely slow. I cannot even use keyboard.

My question is:

I want to check the CR0 register after I disable the cache by setting the CD bit of CR0. So I need to be able to use the keyboard at least.

Is there anyway that can help me use the keyboard after I disable cache?

It's totally out of my expectation that disabling the cache can make the system almost freeze.

Community
  • 1
  • 1
Mike
  • 1,841
  • 2
  • 18
  • 34
  • Is this CPU using integrated graphics? If so, I expect turning off cache also turned it off for the GPU. – Zan Lynx Jan 21 '14 at 23:18
  • 3
    Disabling cache is a bit like throwing a big spanner into your computer's cogwheels. Consider yourself lucky if no driver bluescreened due to excessive bus contention. At least I hope you're not doing that on your developpment machine? A slight error fiddling with cache control registers could crash your PC very badly and there is no telling what kind of garbage the disk I/O could spread through your hard drives. – kuroi neko Jan 22 '14 at 00:29
  • Now you know why there are caches. The answer is "don't disable the caches". – CL. Jan 22 '14 at 09:04
  • 1
    Yeah, seems counter-intuitive, but that's the way it is. I remember my first experiments with cache disabling. Disabling the cache on a 386/33mhz box made it run slower than my 10mhz 8088 (which didn't even have a cache). Got even worse when I got my i486. Disabling the cache on that made it pretty much unusable. – Brian Knoblauch Jan 22 '14 at 12:54
  • Hi @ZanLynx, yest, it uses Integrated graphics. I didn't use the Independent graphics. Actually, I can run it at runlevel 1. But it's still very very slow – Mike Jan 22 '14 at 14:22
  • Hi @kuroineko, Thanks for your advice! I did do it in my experiment machine. I flushed the cache immediately when I disable it. I'm not sure why it can cause excessive bus contention? In my opinion, the same or maybe less amount of data is transfered from Memory to CPU ,bypassing the cache. So I think the workload for bus should be the same or less. Why it can cause more bus contention? – Mike Jan 22 '14 at 14:24
  • Hi @BrianKnoblauch, thank you very much for sharing your knowledge! It's really helpful! Did you investigate why disabling cache makes 386/33MHZ even slower than the 8088/10MHZ without cache? Is it because 386 uses pipeline? – Mike Jan 22 '14 at 14:25
  • I have no idea on the reason. It seems like it should not be so, but the experimental results said that it was indeed so. :-) I'm not a chip designer, so that's pretty much where I stopped. – Brian Knoblauch Jan 22 '14 at 15:10
  • 1
    @MikeXu Well with cache disabled, every single byte used by your CPUs causes a bus access. This is not only about 20 times slower than a normal operation with 95-98% of cache hits, it also means the bus is constantly busy. It means the drivers will be very far from their usual operating conditions. The bluescreen image was a bit extreme, but that could certainly excite the drivers in a very unusual way, increasing the chances of stumbling upon bugs that never occur when the system is responsive enough. – kuroi neko Jan 22 '14 at 15:18
  • Hi @kuroineko, the drivers you mentioned are keyboard and monitor drivers, right? or maybe I/O drivers. Suppose we only look at the keyboard driver, if I type the characters, everytime when I type, the driver takes the char and show it on the screen, so in my opinion, everytime when I type a char, it activate one byte read from memory to CPU no matter cache is enable or disabled. When I type the second char, it loads the char from memory to CPU again. Because the driver cannot know which char I typed, it cannot prefetch the chars to cache. So I think it does NOT affect the bus. – Mike Jan 22 '14 at 16:12
  • HI @kuroineko, maybe if you have any pointer that can back up your argument, could you please share it with me? I can have a look at it and maybe then I can see the reason better? Thank you so much for your discussion with me on this issue! :) – Mike Jan 22 '14 at 16:13
  • 1
    I'm not talking about keyboard driver. More about video card or disk drivers that do DMA all the time and poll bus-locked variables. Now about speed issues, the bus accesses are an order of magnitude slower than cache hits (i.e. 15-30 times slower), that's a general rule-of-thumb. Exact value is of course dependant of the bus controller and memory characteristics. – kuroi neko Jan 22 '14 at 16:26
  • @kuroineko, Thank you very much! Video and disk drivers do make sense. – Mike Jan 22 '14 at 19:22

0 Answers0