2007/8/26, Robert Hancock <[EMAIL PROTECTED]>:
>
> It looks like you have some CONFIG_IDE options enabled in your kernel
> configuration that result in drivers/ide trying to drive part or all of
> that controller, preventing libata from doing so. Likely the easiest
> thing to do is just set CONFIG_
I have been using 2.6.21.1. It seems working well, that is, all my
disk partitions are mapped as "/dev/sda*" and the performance looks
good. After I upgrade to 2.6.22.5 with the exact same configuration,
all the disk device turn to "/dev/hda*" and the performance degrade
obviously.
While I boot wi
y and substitute term
*context* in my previous mail with what you name. But I believe my
other explaination still hold, right?
And again, if anyway I am forced to use your termnology system, I
would also agree your other point regarding hardware.
2007/5/18, Phillip Susi <[EMAIL PROTECTED]>:
causality.
2007/5/16, Phillip Susi <[EMAIL PROTECTED]>:
Dong Feng wrote:
> If what you say were true, then an ISR would be running in the same
> context as the interrupted process.
Yes, and it is, as others have said in this thread, which is a good
reason why ISRs can't sle
2007/5/16, Phillip Susi <[EMAIL PROTECTED]>:
Dong Feng wrote:
>> Doesn't it run in current process's context ?
>>
>
> No. I think the concept of process context is a higher-level logical
> concept. Though the interrupt share stack with the interrupted
>
Yes, you are right in this regard. An interrupt handler does steal the
time slice from the interrupted process.
So now I think it is considered an acceptable deviation in calculating
the process run time as well as determine process scheduling because
an ISR should take very short time to return,
>
> I don't think so but I am not sure.
Aliter, i think so.How can an interrupt's execution time go
unaccounted then?
I guess it does not, only the current processes running
time is accounted for.
Thoughts?
The interrupt handler's execution time will definitely defer the
execution of the proce
good enough, but i have a query regarding this then.
On a 8K kernel stack system, doesn't interrupts share the stack associated
with the current process which was interrupted?
Yes, I think so.
Doesn't interrupt steals the CPU slice time allocated to the running process
to run?
I don't think
I agree that the reason an interrupt can not sleep is because an
interrupt is not associated with any context. But I do not agree that
it is specifically because the scheduler can not *resume* the context.
In early version, the ISR always borrow the stack of the currently
running process, so if t
My understanding is as follows.
Whenever the kernel code sleeps, it means the latest process running
in user space will have to wait for the event on which the kernel code
sleeps.
It makes sense for an exception handler to sleep because an exception
handler always serves the latest process runni
Thank you very much.
2007/2/23, Davide Libenzi :
On Fri, 23 Feb 2007, Dong Feng wrote:
> The __syscallN series macros have disappeared in
> include/asm-i386/unistd.h. Why? I occasionally what to add and use
> some new system calls, mainly for debug use. Now I can not access the
>
The __syscallN series macros have disappeared in
include/asm-i386/unistd.h. Why? I occasionally what to add and use
some new system calls, mainly for debug use. Now I can not access the
system call I added from user space.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
cond_resched() checks and conditionally sets PREEMPT_ACTIVE flag for
the current task. The comments says,
/*
* The BKS might be reacquired before we have dropped
* PREEMPT_ACTIVE, which could trigger a second
* cond_resched() call.
*/
My understanding is that cond_resched() would be indirectly i
explicit voluntary preemption points only, and those
points are determined by invoking cond_resched().
But I still have questions, why cond_resched() does not yield no-op
while CONFIG_PREEMPT is set? And why does it deal with the
PREEMPT_ACTIVE flag anyway?
2007/2/22, Dong Feng <[EMAIL PROTEC
I have a question about cond_resched().
What is the condition under which I should invoke cond_resched() irreplaceably?
For example, I see the following code in ksoftirqd(),
preempt_enable_no_resched();
cond_resched();
preempt_disable();
But I do not understand why I should not write the follo
Function permanent_kmaps_init() take a struct pgd_t as parameter.
I presume passing the struct pgd_t as a parameter is to make the
function flexible in order to reuse it under different cases. However,
I discover the following things imparing the rationality of this
parameter.
1. This function i
16 matches
Mail list logo
