5 ms·

I don't get it. If apps can be paused in the background while remaining in RAM, why not swap them to the SSD when memory runs low? Why quit the app completely a

by chime 17y ago

I don't get it. If apps can be paused in the background while remaining in RAM, why not swap them to the SSD when memory runs low? Why quit the app completely and expect the app to manage restore etc.? When the app restarts, it is obviously going to read from the SSD. So why not load the state too automatically? If paused apps still have open threads that called every now and then, I can understand. But it doesn't make sense for apps that don't. I would appreciate if anyone could explain this better.

guelo 17y ago
The problem with flash memory is that it has a finite number of write cycles, typically around 100,000 though there are techniques that extend that. This is also why the iPhone doesn't utilize a swap file.
- sp332 17y ago
  Modern MLC cells get 1,000-10,000 writes per cell. That's about 1,000,000 writes per drive, with wear leveling.
  - gte910h 17y ago
    You can't get very good wear leveling with a device that's on for days at a time. Flash as a swap drive is still problematic.
    - barrkel 17y ago
      Assume a constant rate of swapping of 128KB/sec evenly distributed across 16GB of storage space. How long before the whole system collapses, as a function of n write cycles? 16 * 1024 * 1024 / 128 * n = 131,072n seconds ~= 1.52n days ~= 0.0042n years So constantly swapping (which is a very pessimistic scenario for a phone, which spends most of its life idle in your pocket) may expect a lifetime between 4.2 and 42 years, presuming between 1,000 and 10,000 write cycles. I would say it's acceptable.
      - ryanpetrich 17y ago
        Except the iPhone (and related devices) don't have wear levelling. Even if they did, there's edge cases where the user fills 95% of the disk and the OS has to page with the remaining 5% (this would require a very intelligent wear levelling algorithm that could optimistically move in-use blocks)
        gte910h 17y ago
        And every wear leveling scheme I've ever seen on a battery powered device happened on bootup. The phone would be restarting all the time, or they'd be doing some sort of weird copy everything background task while the phone was running (and things would get really complicated if you tried to sync in the middle of that).
        ryanpetrich 17y ago
        Wow, that sounds more horrible than I was imagining.
blasdel 17y ago
At least on their earlier hardware, the flash devices were really bad at random writes -- think SD card, not SSD.
- wmf 17y ago
  Who said anything about random writes? If you're swapping out an entire app it could be a single sequential ~20MB write which would take roughly 1 second.
  - blasdel 17y ago
    At the same time most of that 20mb is going to be static stuff that's already in the filesystem anyway. A major tenet of VM design is to never swap shit that's already on disk -- you just throw it away, and load it from disk again when you need it. They could implement some VM magic, but they would much rather you wrote your app to serialize its few kilobytes of state when it's told to be ready to die, and instantiate that state on launch. They've encouraged you to do this and provided APIs to help for a long time. It's a lot more elegant and functional than keeping processes around indefinitely -- then they'd need a task manager UI for discarding fucked serialized processes!
    - barrkel 17y ago
      I think that's a red herring, and static stuff wouldn't be duplicated in practice. Let's break this down by chopping memory into roughly three bins: a) File-backed pages from executables, libraries (i.e. typically shared) b) Non-shared essential memory - the state of the application c) Non-shared discardable memory - state which can be recomputed if necessary, e.g. caches, frame buffers etc. What's the actual upshot difference between the OS doing the serialization (in the form of bulk paging, as opposed to on-demand paging), and asking applications to do it? Memory written out: * OS wants to write out (b) and (c), because it's tricky to express your discardable preferences in memory allocations - not only are the pages discardable, but references into the pages need to be zeroed out. (A GC would help a lot here.) * App can write out (b), but it needs to work quite hard to get there. Likely it will write out a fraction of (b) but do a lot of execution on loading; there may also be bugs or design flaws which lead to less than perfect resumption. Upshot: There should be little to no difference in random access for writing: both should be sequential writes; but less written for the App model. But the OS model has a different advantage: it can lazily be writing out less frequently written pages to disk, so come suspend time, it has less work to do. Memory read in: * OS will read in (a), (b) and (assuming we don't have that GC etc.) (c). (a) will be random reads, while (b) and (c) will be a bulk sequential read. * App will read in (a) and (b). (a) will be random reads, while (b) should be a bulk sequential read. Upshot: There should be little to no difference in random reads, while the App should have a little less sequential reading. So as regards to FS access, I don't see necessarily significant differences in between these two models. A different matter is resources. Things like sockets, open files, events - or god forbid, system-wide synchronization primitives, etc. Some form of managed memory with opaque handles that understand serialization events would help out in the OS front here. But it shouldn't be intractable; Smalltalk systems and the like have been working with persistent images for a long time. I actually think a bigger problem is the dynamically available persistent storage space. Having a device that's supposed to have 8GB or 16GB of memory but finding it only has 6.5 or 13 or so, owing to GiB/etc., formatting and OS installation, is galling enough. But having potential 6x chunks of 0.1 or 0.25 going missing has got to hurt. Compression may help; but it's independent of strategy. What I do think is that an OS and cooperative runtime / GC would do a lot better job of this in terms of user experience than the app writer, who has to balance this requirement with getting all the rest of their app right. The easiest way to do it for the app writer is something along the lines of a save game or a saved document - i.e. persist relevant state, but go through the normal loading cycle at startup before restoring state. Thing is, reinitializing everything is dog slow - many apps take too long to start up, no matter what platform they're running on, desktop or phone.
wvenable 17y ago
When an app is swapped to disk, all it's code and data pages are stored. When it's resumed, the code and data pages are loaded back. This isn't so terribly different from relaunching the application (loading the code) and having the app restore it's state (loading the data). In fact, the app can even be more efficient in saving it's own state because it can discard anything it knows it doesn't need. This sort of system doesn't work on a desktop because you can view/use more than one app at a time. However, it's more than reasonable on a system where you interact with apps one at a time. This is pretty much how all mobile platforms have done it since forever.
- barrkel 17y ago
  A GC and framework designed around this serialization could be made to work, though, greatly reducing the burden on the programmer. Of course since Apple has outlawed innovation in those areas targeting the iPhone, they may never find that out...

by chime 17y ago

guelo 17y ago

The problem with flash memory is that it has a finite number of write cycles, typically around 100,000 though there are techniques that extend that. This is also why the iPhone doesn't utilize a swap file.

sp332 17y ago
Modern MLC cells get 1,000-10,000 writes per cell. That's about 1,000,000 writes per drive, with wear leveling.
- gte910h 17y ago
  You can't get very good wear leveling with a device that's on for days at a time. Flash as a swap drive is still problematic.
  - barrkel 17y ago
    Assume a constant rate of swapping of 128KB/sec evenly distributed across 16GB of storage space. How long before the whole system collapses, as a function of n write cycles? 16 * 1024 * 1024 / 128 * n = 131,072n seconds ~= 1.52n days ~= 0.0042n years So constantly swapping (which is a very pessimistic scenario for a phone, which spends most of its life idle in your pocket) may expect a lifetime between 4.2 and 42 years, presuming between 1,000 and 10,000 write cycles. I would say it's acceptable.
    - ryanpetrich 17y ago
      Except the iPhone (and related devices) don't have wear levelling. Even if they did, there's edge cases where the user fills 95% of the disk and the OS has to page with the remaining 5% (this would require a very intelligent wear levelling algorithm that could optimistically move in-use blocks)
      - gte910h 17y ago
        And every wear leveling scheme I've ever seen on a battery powered device happened on bootup. The phone would be restarting all the time, or they'd be doing some sort of weird copy everything background task while the phone was running (and things would get really complicated if you tried to sync in the middle of that).
        ryanpetrich 17y ago
        Wow, that sounds more horrible than I was imagining.

blasdel 17y ago

At least on their earlier hardware, the flash devices were really bad at random writes -- think SD card, not SSD.

wmf 17y ago
Who said anything about random writes? If you're swapping out an entire app it could be a single sequential ~20MB write which would take roughly 1 second.
- blasdel 17y ago
  At the same time most of that 20mb is going to be static stuff that's already in the filesystem anyway. A major tenet of VM design is to never swap shit that's already on disk -- you just throw it away, and load it from disk again when you need it. They could implement some VM magic, but they would much rather you wrote your app to serialize its few kilobytes of state when it's told to be ready to die, and instantiate that state on launch. They've encouraged you to do this and provided APIs to help for a long time. It's a lot more elegant and functional than keeping processes around indefinitely -- then they'd need a task manager UI for discarding fucked serialized processes!
  - barrkel 17y ago
    I think that's a red herring, and static stuff wouldn't be duplicated in practice. Let's break this down by chopping memory into roughly three bins: a) File-backed pages from executables, libraries (i.e. typically shared) b) Non-shared essential memory - the state of the application c) Non-shared discardable memory - state which can be recomputed if necessary, e.g. caches, frame buffers etc. What's the actual upshot difference between the OS doing the serialization (in the form of bulk paging, as opposed to on-demand paging), and asking applications to do it? Memory written out: * OS wants to write out (b) and (c), because it's tricky to express your discardable preferences in memory allocations - not only are the pages discardable, but references into the pages need to be zeroed out. (A GC would help a lot here.) * App can write out (b), but it needs to work quite hard to get there. Likely it will write out a fraction of (b) but do a lot of execution on loading; there may also be bugs or design flaws which lead to less than perfect resumption. Upshot: There should be little to no difference in random access for writing: both should be sequential writes; but less written for the App model. But the OS model has a different advantage: it can lazily be writing out less frequently written pages to disk, so come suspend time, it has less work to do. Memory read in: * OS will read in (a), (b) and (assuming we don't have that GC etc.) (c). (a) will be random reads, while (b) and (c) will be a bulk sequential read. * App will read in (a) and (b). (a) will be random reads, while (b) should be a bulk sequential read. Upshot: There should be little to no difference in random reads, while the App should have a little less sequential reading. So as regards to FS access, I don't see necessarily significant differences in between these two models. A different matter is resources. Things like sockets, open files, events - or god forbid, system-wide synchronization primitives, etc. Some form of managed memory with opaque handles that understand serialization events would help out in the OS front here. But it shouldn't be intractable; Smalltalk systems and the like have been working with persistent images for a long time. I actually think a bigger problem is the dynamically available persistent storage space. Having a device that's supposed to have 8GB or 16GB of memory but finding it only has 6.5 or 13 or so, owing to GiB/etc., formatting and OS installation, is galling enough. But having potential 6x chunks of 0.1 or 0.25 going missing has got to hurt. Compression may help; but it's independent of strategy. What I do think is that an OS and cooperative runtime / GC would do a lot better job of this in terms of user experience than the app writer, who has to balance this requirement with getting all the rest of their app right. The easiest way to do it for the app writer is something along the lines of a save game or a saved document - i.e. persist relevant state, but go through the normal loading cycle at startup before restoring state. Thing is, reinitializing everything is dog slow - many apps take too long to start up, no matter what platform they're running on, desktop or phone.

wvenable 17y ago

When an app is swapped to disk, all it's code and data pages are stored. When it's resumed, the code and data pages are loaded back. This isn't so terribly different from relaunching the application (loading the code) and having the app restore it's state (loading the data). In fact, the app can even be more efficient in saving it's own state because it can discard anything it knows it doesn't need. This sort of system doesn't work on a desktop because you can view/use more than one app at a time. However, it's more than reasonable on a system where you interact with apps one at a time. This is pretty much how all mobile platforms have done it since forever.

barrkel 17y ago
A GC and framework designed around this serialization could be made to work, though, greatly reducing the burden on the programmer. Of course since Apple has outlawed innovation in those areas targeting the iPhone, they may never find that out...