Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Wed, 2009-06-03 at 14:04 +0100, Catalin Marinas wrote:
Hi,
On Tue, 2009-06-02 at 15:22 +, James Bottomley wrote:
So what we're looking for is a proposal to discuss the issues
most affecting embedded architectures, or preview any features affecting
the main kernel which embedded architectures might need ... or any other
topics from embedded architectures which might need discussion or
debate.
Some issues that come up on embedded systems (and not only):
* Multiple coherency domains for devices - the system may have
multiple bus levels, coherency ports, cache levels etc. Some
devices in the system (but not all) may be able to see various
cache levels but the DMA API (at least on ARM) cannot handle
this. It may be useful to discuss how other embedded
architectures handle this and come up with a unified solution
So this is partially what the dma_sync_for_{device|cpu} is supposed to
be helping with. By and large, the DMA API tries to hide the
complexities of coherency domains from the user. The actual API, as far
as it goes, seems to do this OK. We have synchronisation issues that
mmiowb() and friends help with ... what's the actual problem here?
* Better support for coherent DMA mask - currently ZONE_DMA is
assumed to be in the bottom part of the memory which isn't
always the case. Enabling NUMA may help but it is overkill for
some systems. As above, a more unified solution across
architectures would help
So ZONE_DMA and coherent memory allocation as represented by the
coherent mask are really totally separate things. The idea of ZONE_DMA
was really that if you had an ISA device, allocations from ZONE_DMA
would be able to access the allocated memory without bouncing. Since
ISA is really going away, this definition has been hijacked. If your
problem is just that you need memory allocated on a certain physical
mask and neither GFP_DMA or GFP_DMA32 cut it for you, then we could
revisit the kmalloc_mask() proposal again ... but the consensus last
time was that no-one really had a compelling use case that couldn't be
covered by GFP_DMA32.
* PIO block devices and non-coherent hardware - code like mpage.c
assumes that the either the hardware is coherent or the device
driver performs the cache flushing. The latter is true for
DMA-capable device but not for PIO. The issue becomes visible
with write-allocate caches and the device driver may not have
the struct page information to call flush_dcache_page(). A
proposed solution on the ARM lists was to differentiate (via
some flags) between PIO and DMA block devices and use this
information in mpage.c
flush_dcache_page() is supposed to be for making the data visible to the
user ... that coherency is supposed to be managed by the block layer.
The DMA API is specifically aimed at device to kernel space
coherency ... although if you line up all your aliases, that can also be
device to userspace. Technically though we have two separate APIs for
user-kernel coherency and device-kernel coherency. What's the path
you're seeing this problem down? SG_IO to a device doing PIO should be
handling this correctly.
* Mixed endianness devices in the same system - this may only need
dedicated readl_be/writel_be etc. macros but it could also be
done by having bus-aware readl/writel-like macros
We have ioreadXbe for this exact case (similar problem on parisc)
* Asymmetric MP:
* Different CPU frequencies
* Different CPU features (e.g. floating point only one
some CPUs): scheduler awareness, per-CPU hwcap bits (in
case user space wants to set the affinity)
* Asymmetric workload balancing for power consumption (may
be better to load 1 CPU at 60% than 4 at 15%)
This actually just works(tm) for me on a voyager system running SMP with
a mixed 486/586 set of processors ... what's the problem? The only
issue I see is that you have to set the capabilities of the boot CPU to
the intersection of the mixture otherwise setup goes wrong, but
otherwise it seems to work OK.
James
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Wed, 2009-06-03 at 11:43 -0700, Andrew Morton wrote: On Wed, 3 Jun 2009 18:09:25 +0100 Russell King r...@arm.linux.org.uk wrote: In fact, on ARM the DMA mask is exactly that - it's a 100% proper mask. It's not a bunch of zeros in the MSB followed by a bunch of ones down to the LSB. It can be a bunch of ones, a bunch of zeros, followed by a bunch of ones. The way we occasionally have to deal with this is to trial an allocation, see if the physical address fits, if not free the page and try again with GFP_DMA set. A couple of times I've suggested that we have the ability to allocate one zone per address bit, so a 32-bit machine with 4k pages would end up having 20 zones. Then, your funny DMA mask can be directly passed into the page allocator as a zone mask and voila, I think. The objection I heard to that one is that the zone machinery works better with fewer zones ... but we could certainly align them along known boundaries for allocations (if it's only bit X that's the problem, say, you only need an additional zone covering that one). Based on this, I dug up the initial proposal, it was the Ottawa Kernel Summit in 2005 (I'm a packrat; I keep all my old presentations): http://www.hansenpartnership.com/sites/hansenpartnership.com/files/jejb/kernel_summit_iommu.pdf kmalloc_mask() is right at the end. It basically died for lack of interest and the fact that GFP_DMA32 satisfied 99% of the actual use cases. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote: One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform. ie. On x86, PowerPC and Sparc a kernel image will boot on any machine (assuming the needed drivers are enabled), but this is rarely the case in embedded. Most embedded kernels require explicit board support selected at compile time with no way to produce a generic kernel which will boot on a whole family of devices, let alone the whole architecture. Part of this is a firmware issue, where existing firmware passes very little in the way of hardware description to the kernel, but part is also not making available any form of common language for describing the machine. OK, so my minimal understanding in this area lead me to believe this was because most embedded systems didn't have properly discoverable busses and therefore you had to tailor the kernel configuration exactly to the devices the system had. Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Josh Boyer has already touched on discussing flattened device tree support at kernel summit in an email to the ksummit list last week (quoted below), and I'm wondering if a broader discussing would be warranted. I think that in the absence of any established standard like the PC BIOS/EFI or a real Open Firmware interface, then the kernel should at least offer a recommended interface so that multiplatform kernels are possible without explicitly having the machine layout described to it at compile time. I know that some of the embedded distros are interested in such a thing since it gets them away from shipping separate images for each supported board. ie. It's really hard to do a generic live-cd without some form of multiplatform. FDT is a great approach, but it probably isn't the only option. It would be worth debating. It sounds interesting ... however, it also sounds like an area which might not impact the core kernel much ... or am I wrong about that? The topics we're really looking for the Kernel Summit are ones that require cross system input and which can't simply be sorted out by organising an Embedded mini-summit. Now if flattened device tree could help us out with BIOS, ACPI, EFI and the other myriad boot and identification standards that seem designed to hide system information rather than reveal it, then we might be all ears ... James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 10:52 -0700, David VomLehn wrote: On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. Now, James, I think you haven't been paying attention to the embedded Linux world...asking us to devise *any* process is much more chaotic than herding cats. Expecting something everyone agrees is fair would probably take until at least KS 2010. That being said, we have three people who are listed in MAINTAINERS under embedded Linux. We might start by seeing which of them might take up the mantle and vote on the linux-embedded mailing list. Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 12:30 -0700, Tim Bird wrote: Josh Boyer wrote: 2) Encouraging upstream participation of Embedded distros Things like Moblin and Android are getting a lot of press these days, but embedded distros have been around for a while. Are we getting good participation from these vendors? Is there something we could be doing to encourage such participation? Has CELF helped with this at all? etc CELF tries, but the progress is exceedingly slow. Recently we've been more focused on contracting specific feature work. (E.g. Squashfs mainlining). James Bottomley wrote: Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. With regard to a process to determine representatives, I'm not sure we need one. Based on participation and inclusion in MAINTAINERS, either Matt Mackall or David Woodhouse can represent most embedded issues just fine. And I can say that officially on behalf of CELF and it's members, which would account for a large fraction of the overall embedded community. With regard to topics, do topics drive attendee invitations, or vice-versa? Here's my own issue list: tracing - already well (over?) represented bloat - tracing will help identify performance bloat. As for size bloat, a smaller kernel is always desirable, but we are seeing signs that Moore's law is catching up and making this less an issue (for the kernel - apps still have big problems here.) power management - Use cases for products that spend most of their time off (even while appearing to be running) are of interest. I don't know what the status 'wakelock-like' solutions is. fast boot - kernel is almost done? (!!!) The new target for kernel boot time is 300 milliseconds. Once there, almost all problems are then user space issues. It is interesting how much of a differentiator fast boot became for Linux in netbooks and dual-boot configurations, in just the last 2 years - which just shows that sometimes it pays off to optimize something. ;-) OK, if that's what you all want, that's what we can do ... however, it would likely be the same people discussing the same issues. participation - talking about this is like beating a dead horse (for me at least). I've been working on this for 5 years now, making baby steps forward. The issues are, by now, well understood (I hope). I'm not sure what a KS discussion is going to do to drive issues here. This is what made us suggest the presentation driven approach. We can send people who understand how the kernel development process out anointed as embedded maintainers. However, looking at the arch directory, you have a ton of new kids on the block. We wondered if, perhaps, rather than having seasoned kernel developers reach out to the embedded community, we might try giving the embedded community the opportunity to reach out to us. The topic of flattened device tree look interesting to me (perhaps because I'm a hardened device driver person and things like that always look interesting to me) ... if we can get a few more like that out of the woodwork, this approach might end up being successful. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
On Sun, 2008-07-06 at 17:46 +0200, Denys Vlasenko wrote: The purpose of this patch is to make kernel buildable with gcc -ffunction-sections -fdata-sections. This patch fixes parisc architecture. Updated version - does not try to rename sections which really are expected to be produced by gcc - .text.sys_exit etc. Actually, I've thought about it some more and I don't think your approach is quite right. The way gcc works with -ffunction-sections makes it clear that it expects the section namespace to be scoped left to right. However, by using *.text and *.data, your patch is following a reverse convention (putting your most global name to the right). This is setting us up for a clash with future global section names that our toolchain might emit in future. Since we have to have special handling for your reversed sections in every vmlinux.lds, what about introducing our own namespace instead? So we reserve the global section specifier linux and then make everything a namespace under this. So our constructed text and data sections become linux.text.* and linux.data.* That way we could only ever get a clash if the toolchain decided to use a section global name linux (which we can beat them up over). James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
