[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [linux-team] Multithreading



> Donc maintenant, on pourra faire de vrais threads au niveau du noyau
> (cela reste à voir).

Ben c'est pas parce que les threads sont gardes par des structures de process dans le noyau que ce ne sont pas de vrais threads... 

Mais c'est vrai que ca va ameliorer les choses sur les machines SMP.

	fred


Alexandre Dulaunoy wrote:
> 
> Clone fonctionne assez bien et les performances sont bonnes.
> Mais le problème récurrant était (je dis bien était) le gros lock par
> process qui empéchait de faire du grain fin pour le lock.
> Mais depuis la 2.4 on essaye de limiter au maximum de le gros lock dans
> certaine partie de fonctionnement du noyau.
> Grâce à cela, les performances SMP sont bien meilleurs. au lieu de ne
> rien faire et d'attendre la fin du lock.
> Mais maitenant suite au Patch de Ingo Molnar, les lock complets sont +/-
> terminés.
> 
> Donc maintenant, on pourra faire de vrais threads au niveau du noyau
> (cela reste à voir).
> 
> Merci Ingo....
> 
> Alx
> 
> PS : Maintenant il reste à voir si Linus va intégrer le p
> 
> Date:   Mon, 28 Aug 2000 17:58:45 +0200 (CEST)
> From:   Ingo Molnar <mingo@elte.hu>
> To:     Linus Torvalds <torvalds@transmeta.com>
> Subject: [patch] getting rid of the Big Kernel Spinlock, 2.4.0-test7
> 
> during 2.3 we got rid of 99% of lock_kernel()s within the core kernel.
> IMHO the time has arrived to get rid of the big kernel spinlock forever -
> by changing it to a ordinary semaphore. Most lock_kernel() code paths are
> holding the kernel lock for a long time and they do it rarely - so a
> semaphore is more suited to do this than a spinlock. It's even a speedup
> (and a debugging help), because lock_kernel() will not spin wasting CPU
> cycles anymore.
> 
> the attached biglock-2.4.0-test7-A6 patch implements this and does a
> couple of related cleanups:
> 
> - the impact of the 'big IRQ lock' is smaller as well, thus schedule() now
>   enforces that it is to be called with IRQs turned on. sleep_on() enables
>   IRQs, and entry.S's reschedule as well. (the later is a code path taken
>   by returning IRQ handlers which might not always disable IRQs.)
> 
>   As a result neither release_kernel_lock(), nor the tq_scheduler path
>   needs to do a sti() - which speeds up the common schedule() path. Nor
>   the performance, nor the semantics of sleep_on() are impacted.
> 
> - new sema_locked() added to semaphore.h - similar to is_spin_locked().
> 
> - got rid of asm/smp_lock.h - linux/smplock.h has the generic code, now
>   that no global-IRQ locking logic is present in schedule(). This
>   simplifies things.
> 
> - irqs_enabled() added to asm/hardirq.h.
> 
> the only place that still needs to spin actively is
> reacquire_kernel_lock() - because semaphore.c calls schedule() itself, so
> we cannot call down() at that point. Solving this is not impossible, but
> needs more changes than justified i think.
> 
> the patch has the IMHO nice side-effect of 'speeding up races' - more
> processes can run when the kernel lock is taken because there is no active
> spinning - thus SMP, kernel-lock related races are triggered with higher
> probability.
> 
> the patch compiles/boots/works just fine on SMP and UP x86 systems. Other
> architectures have to add the (trivial and generic) sema_locked() and
> irqs_enabled() functions. The patch should be an invariant and does not
> intend to change semantics of any kernel functionality otherwise.
> 
>         Ingo
> atch sans trop de commentaires ...
> 
> 
> Frédéric Detienne wrote:
> >
> > Je me corige tout de meme c'est la fonction _clone qui est appele et pas vfork. J'avais en tete que ca se nommait vfork dans 2.0 (c'est ca ou un faux souvenir de ma part). J'ai verifie: dans 2.2 fork=vfork (a coup sur).
> >
> > De toute facon, les fonctions p_thread* sont des fonctions de *librairies* qui implementent l'API POSIX. Pas des fonctions du kernel (appels systemes). Au plus bas niveau la librairie finit par faire un _clone.
> >
> > _clone = fork sans duplication de la table des pages ou des descripteurs de fichiers.
> >
> > Donc dans la table des processus, un thread EST un process. Si tu ne me crois pas, fais donc un "man clone" et va lire le code du scheduler.
> >
> > Je n'essayais pas de t'eduquer sur la programmation des threads (si tu poses la question comme ca, tu sais ce que c'est), c'etait pour appuyer mon explication sur le pourquoi du ps qui devrait montrer les threads.
> >
> > Et ca, ce sont pour les threads kernels bien sur. Si tu utilises des threads en user space, rien ne peut t'aider.
> >
> >       fred.
> >
> > ps: c'est drole: je recompte mes doigts et ils sont tous la... et j'ai pourtant le sentiment d'avoir ete mordu.
> >
> >
> > Piette François wrote:
> > >
> > >         > ben sous Linux, les threads sont crees avec vfork.
> > >
> > > Non, pas vraiment. Ils sont créés et manipulés avec une série de fonction
> > > pthread_machin. Mais là n'est pas mon problème. Mes threads se créent bien
> > > et fonctionnent bien.
> > >
> > >         > ps -A S -H devrait te montrer l'arborescence des process
> > >         > spawnes (et par consequent, les threads)
> > >
> > > Un thread n'est PAS un process. C'est une unité d'exécution à l'intérieur
> > > d'un process. Ceci dit, je vais jetter un oeil sur ce que donnent ces
> > > options. Merci.
> > >
> > > --
> > > francois.piette@swing.be
> > > http://www.rtfm.be/fpiette/indexuk.htm
> > >
> > > > Francois PIETTE wrote:
> > > > >
> > > > > Comment afficher la liste des threads d'un processus donné et le %
> > > > > d'utilisation du CPU par chaque thread ? La commande "ps -m" sensée
> > > > afficher
> > > > > les informations des threads me dit "Thread display not implemented".
> > > > >
> > > > > --
> > > > > francois.piette@swing.be
> > > > > http://users.swing.be/francois.piette/indexuk.htm
> > > > >
> > > > > --------
> > > > > Visit the Linux Supertore Online: http://www.redcorp.com !
> > > > > If you want to be deleted from the list, send a mail to
> > > > > majordomo@rtfm.be with "unsubscribe linux-team" in the body.
> > > > > Archive of the list: http://tania.be.linux.org/
> > > > --------
> > > > Visit the Linux Supertore Online: http://www.redcorp.com !
> > > > If you want to be deleted from the list, send a mail to
> > > > majordomo@rtfm.be with "unsubscribe linux-team" in the body.
> > > > Archive of the list: http://tania.be.linux.org/
> > > >
> > > --------
> > > Visit the Linux Supertore Online: http://www.redcorp.com !
> > > If you want to be deleted from the list, send a mail to
> > > majordomo@rtfm.be with "unsubscribe linux-team" in the body.
> > > Archive of the list: http://tania.be.linux.org/
> > --------
> > Visit the Linux Supertore Online: http://www.redcorp.com !
> > If you want to be deleted from the list, send a mail to
> > majordomo@rtfm.be with "unsubscribe linux-team" in the body.
> > Archive of the list: http://tania.be.linux.org/
> >
> 
> --
> ----
> Alexandre.Dulaunoy@ubizen.com
> 
> http://www.ubizen.com
> tel +352 26310585  -  fax +352 26310586
> Ubizen - 166 rue de Dippach - L-8055 Bertrange
> --------------------------------------------------
> "The nice thing about standards is that there are
>  so many of them to choose from." A.S. Tanenbaum
> 
> --------
> Visit the Linux Supertore Online: http://www.redcorp.com !
> If you want to be deleted from the list, send a mail to
> majordomo@rtfm.be with "unsubscribe linux-team" in the body.
> Archive of the list: http://tania.be.linux.org/

-- 
------------------------- * oOo * -------------------------
                     Frederic Detienne
              Cisco Systems Escalation Engineer
                 Security & Network Services

                     Tel 32 2 704 55 55
--------
Visit the Linux Supertore Online: http://www.redcorp.com !
If you want to be deleted from the list, send a mail to
majordomo@rtfm.be with "unsubscribe linux-team" in the body.
Archive of the list: http://tania.be.linux.org/