Hi! > > > "This allocation is temporary. It lasts milliseconds, not hours." > > > > It isn't sufficient to give a rule for when GFP_TEMPORARY will be used, > > you also need to explain (at least in general terms) how the information > > will be used. Also you need to give guidelines on whether the flag > > should be set for allocation that will last seconds or minutes. > > > > If we have a flag that doesn't have a well defined meaning that actually > > affects behavior, it will not be used consistently, and if we ever > > change exactly how it behaves we can expect things to break. So it is > > better not to have a flag, than to have a poorly defined flag. > > Absolutely agreed! > > > My current thoughts is that the important criteria is not how long the > > allocation will be used for, but whether it is reclaimable. Allocations > > that will only last 5 msecs are reclaimable by calling "usleep(5000)". > > Other allocations might be reclaimable in other ways. Allocations that > > are not reclaimable may well be directed to a more restricted pool of > > memory, and might be more likely to fail. If we grew a strong > > "reclaimable" concept, this 'temporary' concept that you want to hold on > > to would become a burden. > > ... and here again. The whole motivation for the flag was to gather > these objects together and reduce chances of internal fragmentation > due to long lived objects mixed with short term ones. Without an > explicit way to reclaim those objects or having a clear checkpoint to > wait for it is not really helping us to reach desired outcome (less > fragmented memory). Really? If you group allocations that last << 1 second, and ones that last >> 1 second, I'm pretty sure it reduces fragmentation... "reclaimable" or not. Fragmentation is just statistical property, so getting it "mostly right" helps... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
