summaryrefslogtreecommitdiffstats
path: root/REPORTING-BUGS
diff options
context:
space:
mode:
authorDavid S. Miller <davem@sunset.davemloft.net>2006-02-02 16:16:24 -0800
committerDavid S. Miller <davem@sunset.davemloft.net>2006-03-20 01:11:34 -0800
commitf4e841da30b4bcbb8f1cc20a01157a788ff58b21 (patch)
tree8f145f6902b694402ce6291a493caf3a2348717e /REPORTING-BUGS
parent7bec08e38a7d0f088994f6eec9b6374652ea71fb (diff)
downloadblackbird-op-linux-f4e841da30b4bcbb8f1cc20a01157a788ff58b21.tar.gz
blackbird-op-linux-f4e841da30b4bcbb8f1cc20a01157a788ff58b21.zip
[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 'REPORTING-BUGS')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud