Originally posted by Delgarde
View Post
Announcement
Collapse
No announcement yet.
Ubuntu Is Going After A New Linux Kernel API
Collapse
X
-
Last edited by jrch2k8; 29 August 2013, 10:18 PM.
-
Originally posted by fscan View PostWhy not write the data to a file then? You could even use the new tmpfile facility (forgot the name) where the file is not visible outside of your process (and gets cleaned up as soon as the process exits). I don't think the kernel will actually write the file if it doesn't have to.
I'm really not seeing why people seem so resistant to this proposal... it seems like a really good idea, not to mention already available in garbage-collected languages (the GC taking the role of the kernel).
Leave a comment:
-
Originally posted by jrch2k8 View Posti doubt you find a game that demanding running in ARM for a while, is not like battefiled 4 will run on ubuntu phone anytime soon
Originally posted by sarmad View PostI fail to understand why Linux doesn't let the user make the decision in low memory situations. How hard is it to just pause everything and display a dialog to the user letting him pick the application to kill/swap out/etc? This would be far more effective, and far easier to implement, than what Canonical is proposing.
Originally posted by r1348 View PostNope, if they work with upstream, this would be a very useful and welcome feature.
Sounds like a good idea to me, and if some desktop apps adhere to such API I might get a performance boost on my old 1GiB RAM Unichrome box.
Originally posted by fscan View PostWhy not write the data to a file then? You could even use the new tmpfile facility (forgot the name) where the file is not visible outside of your process (and gets cleaned up as soon as the process exits). I don't think the kernel will actually write the file if it doesn't have to.
But yeah ... there are cases where this could be useful on low memory devices...
Leave a comment:
-
Originally posted by duby229 View PostI just want to point out 1 thing though, if you have 512MB of RAM being used for cache that means you need to move that much from storage at some point at least once. If you do this too aggressively then storage bandwidth becomes the bottleneck. Another problem is the amount of time needed to move data out of cache for one application to make room for data that a second application needs to load. It's storage bandwidth that suffers the most on too aggressive caching.
Leave a comment:
-
Originally posted by Delgarde View PostBecause it might not be on disk... it might be info that can be re-calculated if needed, but which can be kept in memory for improved performance. E.g a browser might be keeping some rendering/layout structures for tabs that aren't currently visible, to save time if the user switches to them. Easily regenerated if the cache has to be cleared, but keeping it saves a second or two when it's needed.
But yeah ... there are cases where this could be useful on low memory devices...
Leave a comment:
-
Originally posted by Ericg View PostEveryone on mobile is already flash based, everything on desktop is moving TO flash based. SATA 3 is what? 8GB/s? I get that not everything is on flash and SATA3 NOW, but moving forward... ya think will storage bandwidth really be an issue?
Leave a comment:
-
Originally posted by duby229 View PostI just want to point out 1 thing though, if you have 512MB of RAM being used for cache that means you need to move that much from storage at some point at least once. If you do this too aggressively then storage bandwidth becomes the bottleneck. Another problem is the amount of time needed to move data out of cache for one application to make room for data that a second application needs to load. It's storage bandwidth that suffers the most on too aggressive caching.
Leave a comment:
-
Originally posted by Delgarde View PostNot necessarily... if the memory is there, it's arguably bad coding to *not* use it. No point in having all that memory if nothing is using it, so if you've got data that can usefully be kept in memory instead, you might as well.
That's the idea of this proposed API, right? An app might not need 16GB of memory, but if it can find a use for it, it's better than leaving it unused. Then if something else wants memory, the kernel can force the first process to give up the space it doesn't actually need - the current alternative being for the kernel to get an out-of-memory error and just kill one of the processes to free some up.
Leave a comment:
-
Originally posted by Delgarde View PostNot necessarily... if the memory is there, it's arguably bad coding to *not* use it. No point in having all that memory if nothing is using it, so if you've got data that can usefully be kept in memory instead, you might as well.
That's the idea of this proposed API, right? An app might not need 16GB of memory, but if it can find a use for it, it's better than leaving it unused. Then if something else wants memory, the kernel can force the first process to give up the space it doesn't actually need - the current alternative being for the kernel to get an out-of-memory error and just kill one of the processes to free some up.
but in your theoretical case you must prefer to actually force the kernel cache off and don't use the ram because you gain more saving that power since in ARM everything active hurts the battery
Leave a comment:
-
Originally posted by jrch2k8 View Posti do know this, my point is you need a real great number of concurrent applications or a very bad coding to starve the memory
That's the idea of this proposed API, right? An app might not need 16GB of memory, but if it can find a use for it, it's better than leaving it unused. Then if something else wants memory, the kernel can force the first process to give up the space it doesn't actually need - the current alternative being for the kernel to get an out-of-memory error and just kill one of the processes to free some up.
Leave a comment:
Leave a comment: