Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

10 participants
7965 discussions

Memory region attribute bits and multiple mappings

by Rebecca Schultz Zavin

Hey all, While we are working out requirements, I was hoping to get some more information about another related issue that keeps coming up on mailing lists and in discussions. ARM has stated that if you have the same physical memory mapped with two different sets of attribute bits you get undefined behavior. I think it's going to be a requirement that some of the memory allocated via the unified memory manager is mapped uncached. However, because all of memory is mapped cached into the unity map at boot, we already have two mappings with different attributes. I want to understand the mechanism of the problem, because none of the solutions I can come up with are particularly nice. I'd also like to know exactly which architectures are affected, since the fix may be costly in performance, memory or both. Can someone at ARM explain to me why this causes a problem. I have a theory, but it's mostly a guess. I especially want to understand if it's still a problem if we never access the memory via the mapping in the unity map. I know speculative prefetching is part of the issue, so I assume older architectures without that feature don't exhibit this behaviour If we really need all mappings of physical memory to have the same cache attribute bits, I see three workarounds: 1- set aside memory at boot that never gets mapped by the kernel. The unified memory manager can then ensure there's only one mapping at a time. Obvious drawbacks here are that you have to statically partition your system into memory you want accessible to the unified memory manager and memory you don't. This may not be that big a deal, since most current solutions, pmem, cmem, et al basically do this. I can say that on Android devices running on a high resolution display (720p and above) we're easily talking about needing 256M of memory or more to dedicate to this. 2- use highmem pages only for the unified memory manager. Highmem pages only get mapped on demand. This has some performance costs when the kernel allocates other metadata in highmem. Most embedded systems still don't have enough memory to need highmem, though I'm guessing that'll follow the current trend and shift in the next couple of years. 3- fix up the unity mapping so the attribute bits match those desired by the unified memory manger. This could be done by removing pages from the unity map. It's complicated by the fact that the unity map makes use of large pages, sections and supersections to reduce tlb pressure. I don't think this is impossible if we restrict the set of contexts from which it can happen, but I'm imagining that we will also need to maintain some kind of pool of memory we've moved from cached to uncached since the process is likely to be expensive. Quite likely we will have to iterate over processes and update all their top level page tables. These all have drawbacks, so I'd like to really understand the problem before pursuing them. Can the linaro folks find someone who can explain the problem in more detail? Thanks, Rebecca

15 years, 3 months

Budapest summit scheduling

by Jesse Barker

Hi all, For those that are interested in or required to attend additional sessions at the larger LDS or UDS events, at the request of the folks managing the scheduling, I've created blueprints, one for each day, to track the sessions. The reason for this is that the autoscheduler will attempt to honor people's "essential" participation, so if you are marked "essential" for both the mini-summit and another track session, there is increased likelihood that you will not have a conflict. I have limited editorial say in the scheduling, so if there are critical conflicts, I can try to help resolve them. I've put the links to the blueprints under "registration" in the mini-summit event on https://wiki.linaro.org/Events, but for convenience, here they are: https://blueprints.edge.launchpad.net/linaro-graphics-wg/+spec/linaro-graph… https://blueprints.edge.launchpad.net/linaro-graphics-wg/+spec/linaro-graph… https://blueprints.edge.launchpad.net/linaro-graphics-wg/+spec/linaro-graph… I'm still tracking the agenda on the Linaro wiki, but will be moving the day's agenda to each blueprint as the event approaches. cheers, Jesse

15 years, 3 months

CFP: Budapest Mini-summit update

by Jesse Barker

Hi all, The good news is that largely everything is as I announced previously. The tracks have been cleaned up a bit, so the memory management mini-summit is now driven out of the Linaro Graphics track, but the room (Ond) and schedule (M-W afternoons) is still the same. All the info you need on the schedule is here: http://summit.ubuntu.com/uds-o/ The room is supposed to have a projector, be mic'd for live audio and have an IRC channel. Those participating remotely will be interested in the details around the audio and IRC access here: http://uds.ubuntu.com/participate/remote/ A link for the mini-summit event found here: https://wiki.linaro.org/Events goes to the (work in progress) agenda and there is a registration link as well. Please let me know if I've missed any components that need representation, if there are some on there that you feel don't need it, or if there are additional items you'd like to see on the agenda. I have 2 requests of the people that will participate in person: 1) Please "register" to indicate you'll be there in person (or even if you plan on participating remotely). There are a few reasons for this, but the critical one is to make sure we have a big enough room. 2) Sign-up to represent a component, at least in the overview sessions. This is important for sane discussion afterwards. If you don't or can't get write access to the Linaro wiki, just send me email directly and I'll do it by proxy. Also, if you have material that you will "show" people (slides, etc.), please send it to the list ahead of time for the benefit of those participating remotely. Finally, the "project page" for this effort is here on the Linaro wiki: https://wiki.linaro.org/OfficeofCTO/MemoryManagement Thanks again to everyone for their contributions. cheers, Jesse

15 years, 3 months

Split GEM from the rest of DRM

by Jordan Crouse

During the MM BoF at ELC, it seemed to me that one of the things that scared most ARM vendors away from GEM in the first place is that was perceived to be too closely married to the rest of DRM (especially KMS). I know that some might argue that isn't necessarily true and we can go back and forth on that point, but I think it is still valuable to ask this question: How feasible is it to break out the GEM portion of DRM (essentially drm_gem.c) and put it into its own subsystem or library component for use by a DRM or a non DRM component. What parts would a non DRM component be missing to use GEM effectively (authentication comes to mind)? Jordan

15 years, 3 months

Mini-summit (incomplete) details

by Jesse Barker

Hi all, I'll be rolling out the details around the Budapest mini-summit as I get them, so there will be more to follow. You can check out the overall schedule here: http://summit.ubuntu.com/uds-o/ As of right now, viewing by track, the mini-summit is listed in the "other" track, though, this may change over the next few days. Viewing the schedule by day, we are right after lunch through the end of the day on Monday-Wednesday (there are plenaries scheduled for immediately after lunch, but unless there are strong objections, I'd argue for going straight into the summit). And finally, by room, we are in "Ond". For those that will be participating remotely, I don't yet have the details on how to tune in to the audio channel, but the IRC channel will be named for the room we're in; I expect to have the rest of those details later this week or early next. I'll also be creating a blueprint on Launchpad to hold our outline, agenda, notes, minutes, etc. (last cycle we used "gobby" to take notes live, but there were stability issues with the server, so we'll see how that goes). Based upon the discussion from ELC, I would expect much of the first day to be component/subsystem overview; I really think that will be critical to finalizing sane requirements. These discussions do not have to wait until Budapest. If there are questions you would like to see answered, send them along. Also, if folks that are attending in person could let me know directly, it would be good to get an updated headcount of who is coming to make sure I don't need to argue for a bigger room. cheers, Jesse

15 years, 3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig