> "Typically, XCHG instructions, instructions preceded by the LOCK prefix
> and descriptor table accesses are locked cycles. Setting Weak Locking
> allows the data for these accesses to be cached."
> I can add that caching will be write-back caching either at the L1 cache
> level (CPU internal) or at the L2 level (motherboard chipset level).
Is that sufficient I wonder? The implication is that the loop
will be continuously modifying the same data so the memory
interface will be writing out continuously. Assuming, of course,
that weak locking really does expose the locked cycle on the bus
and doesn't do away with it altogether. As I understood it weak
locking is for the case where the data will not be changed by
another device without a locked cycle and the cache knows to
flush on a seeing a locked cycle. Whereas NO_LOCK means, "Who
gives a toss anyway..."
> Now how about the descriptor tables? Could Weak Locking on descriptor
> tables cause a problem for Linux kernels?
No, other than on SMP, because only the CPU cares about them
anyway so if they are cached that's fine. That does bring up
another problem though. I don't know about weak locking but
NO_LOCK applies _only_ to explicit locks. Page table accesses
always occur as locked cycles I think, in which case it _may_
be possible to freeze out the system by doing a tight loop
over an invalidate for the current page and thereby causing
the MMU to generate a locked cycle to reload it?
Mike
-- .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 | | RG40 1XG, ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'