[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some doubts on cache coherence
Hello...
> > 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"
Well, interrupt context is irrelevant with the current running process.
In other word, since interrupt can come at anytime, it is hard to
create direct correlation between interrupt and running process. Here,
I refer to hardware interrupt...
But if you mean something like software interrupt, in other word,
executing system call, then yes, it has correlation. When issuing
system call, kernel is executing the system call handler on behalf of
the process.
User space memory can be swapped out during interrupt context. So if you
must access this swapped out memory region inside the hardware
interrupt handler, you must avoid it! why? because, to swap in the
swapped out pages, kernel needs to generate I/O to disk and it means
going to sleep. And in hardware interrupt handler, it is forbidden to
sleep.
But in system call, it is OK to access swapped out pages, because system
call runs in process context and it is allowed to sleep in process
context.
> 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.
Yes, "sleep" here means put the running process on hold and give other
runnable process a chance to run.
correct, spin_try_lock() tests whether it can grab the lock or not, not
actually grab the lock itself.
> > 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.
:) Ehem, please read kernel book such Understanding The Linux Kernel
first :) It is too long to tell the whole story here...
NB: please keep the kernelnewbies mailing list CC'ed too...
regards
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/