| |||||||||||
little systemslittle systemsPosted Jul 2, 2003 16:25 UTC (Wed) by johnjones (guest, #5462)Parent article: An interview with Linus Torvalds
how about 8MB of RAM and 8MB of ROM do people worry about this ? and can someone please sort out clustering... as more and more SMP systems come about the locking is going to turn into a solaris regards John Jones
(Log in to post comments)
little systems Posted Jul 2, 2003 19:40 UTC (Wed) by jimi (guest, #6655) [Link] Linus has stated previously that scalability goes both ways: large systems and small systems. Software that only scales up isn't very scalable, it must also scale down. So I think he and others are aware of trying to make things work well in very small systems (in fact, newer kernels often have increased performance on the same old hardware).As for SMP, the locking improves constantly. But the best solution probably isn't to have a kernel running on each CPU. Interrupts from the same device aren't always received on the same CPU. Imagine trying to coordinate interrupt processing between seperate kernels. Fouther problems arise in memory management, particularly on non-NUMA systems (which kernel owns which memory? How do you keep one kernel from stomping on the memory of another? How do you allocate large chunks of memory for an app? Let the kernels fight it out? Does that mean that an app would be tied to one kernel?)
definition of scalability Posted Jul 3, 2003 23:09 UTC (Thu) by giraffedata (subscriber, #1954) [Link] >Software that only scales up isn't very scalableThe wording here actually weakens a very good point. There is no such thing as "only scales up." That's like saying a property line only runs East. Scalable means the size can be big or small. If you make Linux work great on a large system and not on a small system, it doesn't scale up. It's always up.
little systems / BIG systems Posted Jul 2, 2003 22:05 UTC (Wed) by StevenCole (guest, #3068) [Link] having a kernel run on each proc or quad rather than 1 kernel is a much better way I thinkThis is probably harder to do than it seems, and it seems pretty difficult. For some light reading, see A Practical Approach to Linux Clusters on SMP Hardware by Karim Yaghmour or Scaling Linux with (partially) CC Clusters by Larry McVoy. This talk, Linux Scalability for Large NUMA Systems, looks like it will be interesting, along with many others. Since Jon will be there, perhaps he can provide a nice review.
little systems Posted Jul 3, 2003 22:55 UTC (Thu) by iabervon (subscriber, #722) [Link] A lot of the big system things are for reducing overhead, which is important when you've got a ton of processes (e.g.) and limited low memory, but also important when you've got some processes and very little total memory.Clustering, for now, seems to work fine without changing the mainline kernel. It's possible that a solution will turn up which is more generally applicable, but, presently, building the hardware for a cluster is enough of an effort that the software aspects aren't that big a deal. A lot of SMP things are now moving to per-processor variables, which gives you a lot of the benefits of per-processor kernels without a lot of the difficulty. Of course, some locks disappear when you compile for uniprocessor, and other locks are actually helpful for handling pre-emption, which is significant for embedded devices and desktops. It's just necessary to put thought into designing locking schemes, and not just throw locks everywhere.
|
|||||||||||