Hello everyone,this is my first time to post a message on this mailing-list.
As we all know the kernel maintain a data struct for the
process(PCB),and also for the thread.Because of the latter's smaller
than the former's,thread switching is faster than the process
switching.And from the book,I read that threads shares some data
information of the process,so my question is that when the threads of
different processes have to switch,and the threads also use some data
of the processes,will the process switch before the threads?The speed
of these threads switching is slower than normal,is that true ?
How can the thread's advantage over process reflect?
--
Support Open Source!
Support Linux (Debian Mandriva ...)!
You are free to use them!
On 9/4/05, Petter Shappen <[email protected]> wrote:
> As we all know the kernel maintain a data struct for the
> process(PCB),and also for the thread.Because of the latter's smaller
> than the former's,thread switching is faster than the process
not really. They just share some bits (like: address space, file
table, signal handlers, etc),
but aside from that - normal processes.
> switching.And from the book,I read that threads shares some data
What exactly is this book you're reading?
> information of the process,so my question is that when the threads of
> different processes have to switch,and the threads also use some data
> of the processes,will the process switch before the threads?The speed
> of these threads switching is slower than normal,is that true ?
Why?
> How can the thread's advantage over process reflect?
It usually don't. Not noticably, in any case
Yesterday I replaced the Winchester 3000+ in my Asus A8v-Deluxe with an
AMD X2 3800+. I had been running a 2.6.12.3 kernel without SMP support.
After installing the new CPU I booted up with no trouble and
reconfigured/recompiled with SMP support. However, upon installing this
kernel, I was unable to boot.
The system's root partition is striped using software raid0, composed of
two partitions on two separate SATA drives. For some reason the block
device files for the second drive were not being automatically created
in /dev, so the array could not be created properly, it only found one
of the two partitions. After a bunch of screwing around to find out what
was going on, I finally wound up adding a bunch of explicit mknod
commands in my initrd's linuxrc, and that fixed the problem.
Of course, the system only stayed up for a minute or less, and then
crashed with an OOPS. I went back to my uniprocessor kernel, downloaded
2.6.13, built that with SMP, again found that I needed to insert
explicit mknod's for the second SATA drive, and finally have a stably
running system.
So, any guesses why with otherwise identical config options, a kernel
with SMP enabled doesn't boot up with all of the device nodes that it
should? (Both drives are on the same controller. I haven't checked to
see if any other device files are missing.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
On 9/5/05, Howard Chu <[email protected]> wrote:
> So, any guesses why with otherwise identical config options, a kernel
> with SMP enabled doesn't boot up with all of the device nodes that it
> should? (Both drives are on the same controller. I haven't checked to
> see if any other device files are missing.)
Devfs is disabled in 2.6.13 as it most likely will be going away soon.
See http://marc.theaimsgroup.com/?l=linux-kernel&m=111939455921877&w=2.
Pekka
Pekka Enberg wrote:
> On 9/5/05, Howard Chu <[email protected]> wrote:
>
>> So, any guesses why with otherwise identical config options, a kernel
>> with SMP enabled doesn't boot up with all of the device nodes that it
>> should? (Both drives are on the same controller. I haven't checked to
>> see if any other device files are missing.)
>>
>
> Devfs is disabled in 2.6.13 as it most likely will be going away soon.
> See http://marc.theaimsgroup.com/?l=linux-kernel&m=111939455921877&w=2.
>
Thanks for the note. I guess I meant udev, or whatever it is that
populates /dev these days.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/