---------- Forwarded message ----------
From: Prabhat Hegde <pubs.hegde@xxxxxxxxx>
Date: Jan 31, 2006 12:39 PM
Subject: Re: some doubts on cache coherence
To: mulyadi.santosa@xxxxxxxxx
Hi,
Thanks for the aid.
> I don't understand, what do you mean by "in case of memory"?
Actually i wanted to know as to what happens to a process when it is executing in user context and interrupt context? Can the memory held by a process while it is executing in interrupt context be swapped out? This was my doubt regarding "in case of memory"
> In general, spin lock is actually a busy loop, while semaphore makes
> you sleep if the lock can't be obtained
> you sleep if the lock can't be obtained
So how different is spin lock? Cos the process seeking the lock will keep spinning on the lock in a tight instruction loop. So in this case also the process is held up as it keeps spinning around the lock. How different is this from sleeping? Wont that CPU runnig the process that is waiting for the lock do some other work? But if spin_try_lock() is used, then thats a different case.
> which cache? L1/L2 cache? page cache? internal disk cache?
well actually all of them as i dont have much knowledge as to what role each one plays.
well actually all of them as i dont have much knowledge as to what role each one plays.
On 1/30/06, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx
> wrote:
Hi...
> 1. What is the difference between interrupt context & user context in
> case of memory. (user space & kernel space related)
I don't understand, what do you mean by "in case of memory"?
> 2. How internally a spinlock is different from a semaphore?
In general, spin lock is actually a busy loop, while semaphore makes
you sleep if the lock can't be obtained.
> 3. Cache coherence in linux 2.6 kernels? (detailed explaination is
> greatly appreciated)
which cache? L1/L2 cache? page cache? internal disk cache?
regards
Mulyadi
