lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Cache coherency... and locking
Date
On Fri, 21 Jul 2000 09:21:47 -0700, 
"Linda Walsh" <law@sgi.com> wrote:
>So it sounds like the safest way to do things is to use a spinlock on a per-process
>basis -- which should almost never fail resulting in mininal overhead. If I want
>to globally turn audit on/off, I need to lock the task struct and walk through
>it setting audit on/off flags to allowed values. The thing that is a pain is
>that the auditmask is 256 bytes long or a full cache line.

I assume you meant 256 bits not bytes, 256 bytes is larger than many
cache lines.

If the data is in task struct *and* you only update it in response to
requests from the current task then you do not need any locks, the fact
that you are running under the current task is enough. But if you want
to update audit flags in one task from another task's context or from
interrupt then you need a lock.

>Checking an extra
>byte would require two cache loads if auditing is turned on. Maybe it would
>be better just to reserve the sign bit of first audit mask as the on/off flag --
>if I can ensure the entire audit mask is in 1 32-byte cache line should minimize
>performance hit. Yes? I'm assuming the fastest portable way to check that 1 bit
>would be (val<0)

Use the test_bit macros, they already exist and are portable.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.100 / U:0.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site