:: Re: [DNG] Systemd as tragedy
Etusivu
Poista viesti
Vastaa
Lähettäjä: Alessandro Selli
Päiväys:  
Vastaanottaja: dng
Aihe: Re: [DNG] Systemd as tragedy
On 02/02/19 at 03:41, Steve Litt wrote:
> Of course, with cars, this complexity is partially
> necessary because to raise MPG (Miles Per Gallon) you need a computer
> to micromanage timing and amount of spark, air, fuel, and how they
> interact. I know of no similar necessity with computers.



  You must never have dealt with *aaS, you must never have done
fine-tuning and intelligent, dynamical resources allocation to Linux
clusters or to heavily multithreading applications.

  What they're doing on cars is the application to mechanics of what has
been done to computers for many years.  Just look at how complex just
RAM management has become in Linux:

* fixed 4KiB pages have become Huge Pages (2MiB, up to 1GiB per page
depending on architecture)

* madvise and fadvise syscalls can advise the kernel about predicted
(=future) memory allocation needs that alter the way the kernel
allocates pages

* shmem is an internal RAM resident filesystem used to manage shared memory

* membarrier() system call allows issuing memory barriers across all
running threads

* heap placement is performed by a pseudo-random algorithm

* VMA (Virtual Memory Address) base address allocation also is

* you can choose between at least three SLAB (kernel objects memory
allocation algorithm) allocators (depending on architecture): ALSB
(regular allocator), SLOB (Simple Allocator) and SLUB (Unqueued Allocator)

* automatic merging of slab caches to reduce kernel memory fragmentation

* NUMA (Non-Uniform Memory Access) aware memory placement

* Control Group support for mem allocation, HugeTLB allocation

* support for Remote Direct Memory Access (DMA over TCP/IP)

* support for zero-copy (buffer-to-buffer data shuffling)

* copy-on-write (sharing of same-page between different processes)

* support for Translation Lookaside Buffer (a cache of physical RAM
addresses)

* support of persistent or ephemeral Transcedent memory, ie "memory that
is of unknown and dynamically variable size, addressable only indirectly
by the kernel" (Wikipedia)

This is just what I could recollect from my kernel-configuration
sessions.  How many of the entries in /proc/vmstat can you tell what
they are and do?

  Then there are process-management features, CPU allocation strategies,
bandwidth allocation algorithms and policies, a huge amount of
networking parameters, queues and algorithms to fine tune cache,
bandwith and buffer allocation, control exaustion, bottlenecks and
latency, filesystem parameters and features too many to number, and of
course all sets of security and corruption prevention and mitigation
policies and algorithms.


Computers have become enormously more complicated from the '60ies than
cars and auto repair shop have.



--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE