Corey An Operating System for Many Cores cs科里操作系统多核 CS.uh.pptVIP

CONCLUSIONS In order for applications to scale up on multicore architectures, they must control sharing Since this new requirement greatly complicates the design of applications, it is best suited to application frameworks such as MapReduce Address ranges (III) Kernel-provided abstraction specifying a virtual-to-physical mapping for a range ofvirtual addresses If multiple cores include the same address range in their address space they will share the same mapping to the same physical pages Each core can freely manipulate and delete mapping in private address ranges w/o any consequences for other core performance Kernel cores In most OS, system calls are executed on the core of the invoking process Bad idea if the system call needs to access large shared data structures Kernel cores let applications dedicate cores to run specific kernel functions Avoids inter-core contention over the data these functions access Symmetric multiprocessing (I) Each core can execute both user and kernel code No execution bottleneck Useror kernel code Useror kernel code ... Symmetric multiprocessing (II) Works very well unless too many kernel function instances access large shared data structures Contention Useror kernel code Useror kernel code Shareddata The solution Run kernel functions that access large shared data structures No inter-core contention Useror kernel code Useror kernel code Shareddata Kernel code Shares (I) Many kernel operations involve looking up identifiers in tables to obtain a pointer to a given kernel data structure (file descriptor entry, …) Lookup tables for kernel objects that let applications specify which object identifiers are visible to other cores Each application core has a root share that is private to that core Needs no locks since its private Shares (II) If two cores want to “share a share,” they create one and add the share ID to either Their private root shares or A share reachable from these root shares Allows applicat