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/
