Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.arch Subject: Re: Making Lemonade (Floating-point format changes) Date: Tue, 14 May 2024 17:51:15 +0300 Organization: A noiseless patient Spider Lines: 51 Message-ID: <20240514175115.00000516@yahoo.com> References: <20240513151647.0000403f@yahoo.com> <9c79fb24a0cf92c5fac633a409712691@www.novabbs.org> <01b78f15d6b5f87809163ce539356ef2@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Tue, 14 May 2024 16:51:18 +0200 (CEST) Injection-Info: dont-email.me; posting-host="dcb64060f415e7fe23ed2e09ecf0fa94"; logging-data="242832"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19eBMsJbHU4IPUzzAxgd5NC9lgvjxaku+8=" Cancel-Lock: sha1:JW8NQ/o4LeD9sEKdFvX3gqOKVWo= X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32) Bytes: 3670 On Tue, 14 May 2024 13:49:09 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > mitchalsup@aol.com (MitchAlsup1) writes: > >BGB wrote: > > >>>> Also I may need to rework how page-in/page-out is handled (and > >>>> or how IO is handled in general) since if a page swap needs to > >>>> happen while IO is already in progress (such as a page-miss in > >>>> the system-call process), at present, the OS is dead in the > >>>> water (one can't access the SDcard in the middle of a different > >>>> access to the SDcard). > >>> > >>> Having a HyperVisor helps a lot here, with HV taking the page > >>> faults of the OS page fault handler. > > > >> Seems like adding another layer couldn't help with this, unless it > >> also abstracts away the SDcard interface. > > > >With a HV, GuestOS does not "do" IO is paravirtualizes it via HV. > > Actually, that's not completely accurate. With PCI Express SR-IOV, > an I/O MMU and hardware I/O virtualization, the guest accesses the > I/O device hardware directly and initiates DMA transactions > to-or-from the guest OS directly. With the PCIe PRI (Page Request > Interface), the guest DMA target pages don't need to be pinned by the > hypervisor; the I/O MMU will interrupt the hypervisor to make the > page present and pin it and the hardware will then do the DMA. > Sounds like it could be problematic from real-time perspective. When I design PCIe devices, I sometimes have device-side FIFO sufficient for 2-5 times an expected worst-case PCIe latency, i.e. for 7-10 usec or so. In scenario, you describe, it could easily overflow for acquisition-type device or underflow for player-type device. Now, my devices are not intended to be plugged into visualized server, but I'd think that I am not the only designer that choses size of FIFOs by that sort of logic. > > >So, having a GuestOS in a position it cannot deal with another page > >fault is no longer a hindrance:: GuestOS does not see that page > >fault; it is just handled and goes away. > > There are two levels of page faults - at the guest level, the > guest handles everything. When the hypervisors supports > multplexing multple guests on a core, it will only handle second > level translation table faults.