diff options
author | David S. Miller <davem@sunset.davemloft.net> | 2006-02-02 16:16:24 -0800 |
---|---|---|
committer | David S. Miller <davem@sunset.davemloft.net> | 2006-03-20 01:11:34 -0800 |
commit | f4e841da30b4bcbb8f1cc20a01157a788ff58b21 (patch) | |
tree | 8f145f6902b694402ce6291a493caf3a2348717e /arch/sparc64/kernel/smp.c | |
parent | 7bec08e38a7d0f088994f6eec9b6374652ea71fb (diff) | |
download | kernel_samsung_smdk4412-f4e841da30b4bcbb8f1cc20a01157a788ff58b21.zip kernel_samsung_smdk4412-f4e841da30b4bcbb8f1cc20a01157a788ff58b21.tar.gz kernel_samsung_smdk4412-f4e841da30b4bcbb8f1cc20a01157a788ff58b21.tar.bz2 |
[SPARC64]: Turn off TSB growing for now.
There are several tricky races involved with growing the TSB. So just
use base-size TSBs for user contexts and we can revisit enabling this
later.
One part of the SMP problems is that tsb_context_switch() can see
partially updated TSB configuration state if tsb_grow() is running in
parallel. That's easily solved with a seqlock taken as a writer by
tsb_grow() and taken as a reader to capture all the TSB config state
in tsb_context_switch().
Then there is flush_tsb_user() running in parallel with a tsb_grow().
In theory we could take the seqlock as a reader there too, and just
resample the TSB pointer and reflush but that looks really ugly.
Lastly, I believe there is a case with threads that results in a TSB
entry lock bit being set spuriously which will cause the next access
to that TSB entry to wedge the cpu (since the TSB entry lock bit will
never clear). It's either copy_tsb() or some bug elsewhere in the TSB
assembly.
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch/sparc64/kernel/smp.c')
0 files changed, 0 insertions, 0 deletions