Il va falloir que tu m'expliques en quoi c'est complétement différent. Pour, c'est le même problème, ou du moins, le SMP est juste un sous problème du cluster. Le projet SMP avait pour but d'augmenter la localité des données, et d'isoler les sous-systèmes tout en peremttant d'avoir des mécanismes de communication et de serialisation performants. Pour moi, c'est exactement ce qui est nécessaire pour faire un OS de cluster. Après, la partie restante, la cohérence de cache a je pense été abandonnée (j'en sais rien), parce que les nouveaux processeurs ccNUMA ou SMP gèrent ça eux même.
Il me semble que le SMP est juste un moyen, pas un but.
Well I strongly believe that any project needs to have an unattainable goal, and our unattainable goal (which I hope actually winds up being attainable) is to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image). It is something that no non-commercial system today can do (the type of clustering Linux supports isn't even close to the type of clustering that we have as our goal, and clustering has never been one of the other BSD's goals as far as I can tell).
In the short term, I have become very exciting about our light weight kernel threading technology, in particular the methodlogy we are adopting to serialize data access by partitioning major subsystems into threads instead of serializing data access with mutexes (FreeBSD-5 and Linux use a mutex-centric model, DragonFly uses a thread-centric model). The reason for this excitement is that it is becoming clear to us that we can develop very clean-looking, elegant, debuggable, SMP scaleable software using this model whereas using the mutex model generally results in much less elegant (even ugly), difficult-to-debug code. Code complexity and code quality is a very important issue in any large piece of software and we believe we have hit on a model that directly addresses the issue in an SMP environment without compromising performance.
[^] # Re: Une ch'tite erreur sur le but initial
Posté par Enj0lras . En réponse à la dépêche DragonFlyBSD 3.2, la libellule s’envole toujours plus haut. Évalué à 10.
Il va falloir que tu m'expliques en quoi c'est complétement différent. Pour, c'est le même problème, ou du moins, le SMP est juste un sous problème du cluster. Le projet SMP avait pour but d'augmenter la localité des données, et d'isoler les sous-systèmes tout en peremttant d'avoir des mécanismes de communication et de serialisation performants. Pour moi, c'est exactement ce qui est nécessaire pour faire un OS de cluster. Après, la partie restante, la cohérence de cache a je pense été abandonnée (j'en sais rien), parce que les nouveaux processeurs ccNUMA ou SMP gèrent ça eux même.
Il me semble que le SMP est juste un moyen, pas un but.