Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: [PATCH 11/12] md: convert cpu notifier to return encapsulate errno value
Next: [GIT PULL] vhost-net fixes for issues in 2.6.34-rc1
From: drepper on 18 Mar 2010 14:30 On Thu, Mar 18, 2010 at 09:13, Ingo Molnar <mingo(a)elte.hu> wrote: > The suckage of kernel async IO is for similar reasons: there's an ugly package > separation problem between the kernel and between glibc Bollocks. glibc would use (and is using) everything the kernel provides. We even have an implementation using the current AIO code. It only works in some situations but that's what the few users are OK with. Don't try to blame anyone but kernel people for the complete and utter failure of AIO in Linux. I don't know how often I've discussed design of a kernel interface with various kernel developers. Heck, whenever Zach Brown and I meet there never is a different topic. And following these meetings the ball is not and cannot be in my court. How could it?
From: drepper on 18 Mar 2010 15:40 On Thu, Mar 18, 2010 at 12:15, Ingo Molnar <mingo(a)elte.hu> wrote: > I didnt say it's glibc's fault - if then it's more of the kernel's fault as > most of the complexity is on that side. I said it's due to the fundamental > distance between the app that makes use of it, the library and the kernel, and > the resulting difficulties in getting a combined solution out. This is wrong, too. Once there is a kernel patch that has a reasonable syscall interface it's easy enough to hack up the glibc side. Don't try to artificially find an argument to support your thesis. If kernel developers always need an immediate itch which lives inside the kernel walls to make a change this is a failure of the kernel model and mustn't be "solved" by dragging ever more code into the kernel. Aside, you don't need a full-fledged glibc implementation for testing. Especially for AIO it should be usable in much lighter-weight contexts than POSIX AIO. These wrappers are even more easy to hack up (and have been in the few cases where some code has been produced). For AIO the situation isn't that the people interested in working on it don't know or care about the use. Zach (through Oracle's products) is very much interested in the code and knows how it should look like. Face it, AIO is an example of a complete failure of the kernel developers to provide something usable. This was the argument and where you started the misdirection of including other projects in the reasoning.
From: Frank Ch. Eigler on 18 Mar 2010 16:00 Frederic Weisbecker <fweisbec(a)gmail.com> writes: > [...] It is actually because both kernel and user side are sync in > this scheme. [...] This argues that co-evolution of an interface is easiest on the developers if they own both sides of that interface. No quarrel. This does not argue that that the preservation of a stable ABI is best done this way. If anything, it makes it too easy to change both the provider and the preferred user of the interface without noticing unintentional breakage to forlorn out-of-your-tree clients. - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: drepper on 18 Mar 2010 16:40 On Thu, Mar 18, 2010 at 13:18, Ingo Molnar <mingo(a)elte.hu> wrote: > Where 'reasonable' is defined by you, right? Not only by me. For some of the AIO approaches which happened there were also glibc patches other people wrote. It's pretty simple. > As i said, the KAIO situation is mostly the kernel's fault, but you are a > pretty passive and unhelpful entity in this matter too, arent you? How'd you guess? I've always been been willing to discuss interface requirements with whoever showed interest in implementing things. Again, ask Zach. I think Christoph Lameter also was involved as were various SGI people over the years. Short of actually doing all the work myself I've done what can be expected. > For example, just to state the obvious: libaio has been written 8 years ago in > 2002 and has been used in apps early on. Why arent those kernel APIs, while > not being a full/complete solution, supported by glibc, and wrapped to > pthreads based emulation on kernels that dont support it? You never looked at the glibc code in use and didn't read what I wrote before. We do have an implementation of libaio using those interfaces. They exist in the Fedora/RHEL glibc and are probably copied elsewhere, too. The code is not upstream because it is not general enough. It simply doesn't work in all situations. The problem with using it (among others) is that certain operations cannot be implemented. And that's not a kernel interface problem. I cannot just switch to using the pthread-based code when coming across something that's not implementable because then the requests have already been sent to the kernel. Only code that knows about the limitations ahead of time can use the KAIO code. > Why isnt glibc itself making use of those AIO capabilities internally? (even > if it's not possible to support full POSIX AIO) For what? glibc doesn't implement anything requiring AIO. The only non-trivial file handling is in nscd and nscd uses memory mapped files. > I checked today's glibc repo, and there's no sign of any of that: Check the Fedora/RHEL/... source files. > Getting _something_ into glibc would certainly help move the situation. No it won't as the 7+ since Jakub wrote the code nothing came out of it. And before you again make groundless claims, there was plenty of discussions with kernel people at the time when the code was written. > it's certainly capable enough to run DB servers. glibc > using it would create further demand (and pressure, and incentives) for > improvements. There simply is no need for AIO in glibc internally. Well, there might be, if it could be used on sockets. But that's not the case. > Charming argumentation style, i really missed it. Well, then this last mail should show you. Without knowing the subject matter, just based on flawed lookups you try to spread the blame to make sure that no mud ever sticks to development process you are so fond of. Sorry to disappoint you.
From: Paul Mundt on 19 Mar 2010 05:30
On Thu, Mar 18, 2010 at 11:11:43AM -0500, Anthony Liguori wrote: > On 03/18/2010 10:17 AM, Ingo Molnar wrote: > >* Anthony Liguori<anthony(a)codemonkey.ws> wrote: > >>On 03/18/2010 08:00 AM, Ingo Molnar wrote: > >>>>[...] kvm in fact knows nothing about vga, to take your last example. > >>>>[...] > >>>> > >>>Look at the VGA dirty bitmap optimization a'ka the KVM_GET_DIRTY_LOG > >>>ioctl. > >>> > >>>See qemu/kvm-all.c's kvm_physical_sync_dirty_bitmap(). > >>> > >>>It started out as a VGA optimization (also used by live migration) and > >>>even today it's mostly used by the VGA drivers - albeit a weak one. > >>> > >>>I wish there were stronger VGA optimizations implemented, copying the > >>>dirty bitmap is not a particularly performant solution. (although it's > >>>certainly better than full emulation) Graphics performance is one of the > >>>more painful aspects of KVM usability today. > >>> > >>We have to maintain a dirty bitmap because we don't have a paravirtual > >>graphics driver. IOW, someone needs to write an Xorg driver. > >> > >>Ideally, we could just implement a Linux framebuffer device, right? > >> > >No, you'd want to interact with DRM. > > Using DRM doesn't help very much. You still need an X driver and most > of the operations you care about (video rendering, window movement, etc) > are not operations that need to go through DRM. > > 3D graphics virtualization is extremely difficult in the non-passthrough > case. It really requires hardware support that isn't widely available > today (outside a few NVIDIA chipsets). > Implementing a virtualized DRM/KMS driver would at least get you the framebuffer interface more or less for free, while allowing you to deal with the userspace side of things incrementally (ie, running a dummy xorg on top of the virtualized fbdev until the DRI side catches up). It would also enable you to focus on the 2D and 3D parts independently. > It doesn't provide the things we need to a good user experience. You > need things like an absolute input device, host driven display resize, > RGBA hardware cursors. None of these go through DRI and it's those > things that really provide the graphics user experience. > None of these things negate the benefit one would get from a virtualized DRM/KMS driver either. There are multiple problems that need solving in this area, and it's a bit disingenuous to discount a valid suggestion out of hand due to the fact it doesn't solve all of the outstanding issues. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |