Re: wake_up vs. wake_up_sync
Does reschedule_idle() ever cause the current CPU to get scheduled? That
is, if someone calls wake_up() and wakes up a higher-priority process
could reschedule_idle() potentially immediately switch the current CPU
to that higher-priority process?
Because this is NOT what I want to happen (it would produce a deadlock
in this particular situation). Having other CPUs get scheduled is ok,
but having the process that called wake_up() get kicked out would be
very bad. In that case I suppose I will have to use wake_up_sync().
Would the following be an appropriate solution?
{
wake_up_sync(>q);
/* Potential deadlock situation */
user_unlock(>lock);
/* Potential for deadlock has passed */
reschedule_idle();
}
Thanks,
Scott
Manfred Spraul wrote:
>
> > I'm having trouble understanding the difference between these.
> > Synchronous apparently causes try_to_wake_up() to NOT call
> > reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
> > assume it just looks for an idle CPU and makes that CPU reschedule.
> >
> > What is the purpose of wake_up_sync?
>
> Avoid the reschedule_idle() call - it's quite costly, and it could cause
> processes jumping from one cpu to another.
>
> > Why would you want to prevent
> > reschedule_idle()?
> >
> If one process runs, wakes up another process and _knows_ that it's
> going to sleep immediately after the wake_up it doesn't need the
> reschedule_idle: the current cpu will be idle soon, the scheduler
> doesn't need to find another cpu for the woken up thread.
>
> I think the pipe code is the only user of _sync right now - pipes cause
> an incredible amount of task switches.
>
> --
> Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
wake_up vs. wake_up_sync
I'm having trouble understanding the difference between these. Synchronous apparently causes try_to_wake_up() to NOT call reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I assume it just looks for an idle CPU and makes that CPU reschedule. What is the purpose of wake_up_sync? Why would you want to prevent reschedule_idle()? Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
wake_up vs. wake_up_sync
I'm having trouble understanding the difference between these. Synchronous apparently causes try_to_wake_up() to NOT call reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I assume it just looks for an idle CPU and makes that CPU reschedule. What is the purpose of wake_up_sync? Why would you want to prevent reschedule_idle()? Scott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up vs. wake_up_sync
Does reschedule_idle() ever cause the current CPU to get scheduled? That
is, if someone calls wake_up() and wakes up a higher-priority process
could reschedule_idle() potentially immediately switch the current CPU
to that higher-priority process?
Because this is NOT what I want to happen (it would produce a deadlock
in this particular situation). Having other CPUs get scheduled is ok,
but having the process that called wake_up() get kicked out would be
very bad. In that case I suppose I will have to use wake_up_sync().
Would the following be an appropriate solution?
{
wake_up_sync(wq-q);
/* Potential deadlock situation */
user_unlock(wq-lock);
/* Potential for deadlock has passed */
reschedule_idle();
}
Thanks,
Scott
Manfred Spraul wrote:
I'm having trouble understanding the difference between these.
Synchronous apparently causes try_to_wake_up() to NOT call
reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
assume it just looks for an idle CPU and makes that CPU reschedule.
What is the purpose of wake_up_sync?
Avoid the reschedule_idle() call - it's quite costly, and it could cause
processes jumping from one cpu to another.
Why would you want to prevent
reschedule_idle()?
If one process runs, wakes up another process and _knows_ that it's
going to sleep immediately after the wake_up it doesn't need the
reschedule_idle: the current cpu will be idle soon, the scheduler
doesn't need to find another cpu for the woken up thread.
I think the pipe code is the only user of _sync right now - pipes cause
an incredible amount of task switches.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Threads and the LDT (Intel-specific)?
I'm trying to do something a bit unorthodox: I want to share the address space between threads, but I want a certain region of the address space to be writeable only for a particular thread -- for all other threads this region is read-only. I've considered several approaches. I'll only go over the one I think is the best solution. I would appreciate any comments folks might have: When linking the userspace program, I instruct the linker to avoid the region from VMA 0 to VMA 0x40. Then, in the userspace code, I duplicate the GDT entries for CS, DS, ES, SS into the LDT, except that the new segments begin at 0x40, instead of 0. I load the segment registers with these LDT entries. In the "write-allowed" thread I create an LDT entry to address VMA 0 through VMA 0x40, in read-write mode. In all the other threads I create an LDT entry to address the same area in read-only mode. This gives me a 4M region at the bottom of memory that is accessible in different ways to different threads. I can also use the LDT to point to thread-specific segments. IMHO this is much better than the stack trick used by linuxthreads. The problem is, I don't fully understand how to use modify_ldt(). Is anyone knowledgeable about this? If anyone has any other suggestions, please let me know. If you are confused as to why I would ever want to do this in the first place, I'd be willing to go over it off the list. Thanks, Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Threads and the LDT (Intel-specific)?
I'm trying to do something a bit unorthodox: I want to share the address space between threads, but I want a certain region of the address space to be writeable only for a particular thread -- for all other threads this region is read-only. I've considered several approaches. I'll only go over the one I think is the best solution. I would appreciate any comments folks might have: When linking the userspace program, I instruct the linker to avoid the region from VMA 0 to VMA 0x40. Then, in the userspace code, I duplicate the GDT entries for CS, DS, ES, SS into the LDT, except that the new segments begin at 0x40, instead of 0. I load the segment registers with these LDT entries. In the write-allowed thread I create an LDT entry to address VMA 0 through VMA 0x40, in read-write mode. In all the other threads I create an LDT entry to address the same area in read-only mode. This gives me a 4M region at the bottom of memory that is accessible in different ways to different threads. I can also use the LDT to point to thread-specific segments. IMHO this is much better than the stack trick used by linuxthreads. The problem is, I don't fully understand how to use modify_ldt(). Is anyone knowledgeable about this? If anyone has any other suggestions, please let me know. If you are confused as to why I would ever want to do this in the first place, I'd be willing to go over it off the list. Thanks, Scott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux OS boilerplate
I've been poring over the x86 boot code for a while now and I've been considering writing a FAQ on the boot process (mostly for my own use, but maybe others will be interested). This would include all relevant information on setting up the x86 hardware for a boot (timers, PIC, A20, protected mode, GDT, initial page tables, initial TSS, etc). The motivation behind this is that I would like to use the Linux boot system as a boilerplate booter for some experimental code. It's probably much cleaner and more robust than any boot loader I might come up with. Does there exist an outline (detailed or not) of the boot process from the point of BIOS bootsector load to when the kernel proper begins execution? If not would anyone be willing to help me understand bootsect.S and setup.S enough so that I might write such an outline? If no one can help me, would you consider it appropriate for me to send email to the people listed in bootsect.S and setup.S asking for assistance? Thanks, Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux OS boilerplate
I've been poring over the x86 boot code for a while now and I've been considering writing a FAQ on the boot process (mostly for my own use, but maybe others will be interested). This would include all relevant information on setting up the x86 hardware for a boot (timers, PIC, A20, protected mode, GDT, initial page tables, initial TSS, etc). The motivation behind this is that I would like to use the Linux boot system as a boilerplate booter for some experimental code. It's probably much cleaner and more robust than any boot loader I might come up with. Does there exist an outline (detailed or not) of the boot process from the point of BIOS bootsector load to when the kernel proper begins execution? If not would anyone be willing to help me understand bootsect.S and setup.S enough so that I might write such an outline? If no one can help me, would you consider it appropriate for me to send email to the people listed in bootsect.S and setup.S asking for assistance? Thanks, Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
