threads questions

threads questions

[Petter Shappen]

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!

Re: threads questions

[Alex Riesen]

On 9/4/05, Petter Shappen <shappen@gmail.com> 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

2.6, devfs, SMP, SATA

[Howard Chu]

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/

Re: 2.6, devfs, SMP, SATA

[Pekka Enberg]

On 9/5/05, Howard Chu <hyc@symas.com> 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

Re: 2.6, devfs, SMP, SATA

[Howard Chu]

Pekka Enberg wrote:
> On 9/5/05, Howard Chu <hyc@symas.com> 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/