search for: _incremental_

...be *all* memory you will ever free, then you have already lost. Just do it in chunks. I don't want the VM code to even fill in that big of an array anyway - this all happens under the zone lock, and you're walking a list that is bad for caching anyway. So plan on an interface that allows _incremental_ freeing, because any plan that starts with "I worry that maybe two TERABYTES of memory isn't big enough" is so broken that it's laughable. That was what I tried to encourage with actually removing the pages form the page list. That would be an _incremental_ interface. You can rem...

...be *all* memory you will ever free, then you have already lost. Just do it in chunks. I don't want the VM code to even fill in that big of an array anyway - this all happens under the zone lock, and you're walking a list that is bad for caching anyway. So plan on an interface that allows _incremental_ freeing, because any plan that starts with "I worry that maybe two TERABYTES of memory isn't big enough" is so broken that it's laughable. That was what I tried to encourage with actually removing the pages form the page list. That would be an _incremental_ interface. You can rem...

On 07/11/2018 05:21 PM, Michal Hocko wrote: > On Tue 10-07-18 18:44:34, Linus Torvalds wrote: > [...] >> That was what I tried to encourage with actually removing the pages >> form the page list. That would be an _incremental_ interface. You can >> remove MAX_ORDER-1 pages one by one (or a hundred at a time), and mark >> them free for ballooning that way. And if you still feel you have tons >> of free memory, just continue removing more pages from the free list. > We already have an interface for tha...

On 07/11/2018 05:21 PM, Michal Hocko wrote: > On Tue 10-07-18 18:44:34, Linus Torvalds wrote: > [...] >> That was what I tried to encourage with actually removing the pages >> form the page list. That would be an _incremental_ interface. You can >> remove MAX_ORDER-1 pages one by one (or a hundred at a time), and mark >> them free for ballooning that way. And if you still feel you have tons >> of free memory, just continue removing more pages from the free list. > We already have an interface for tha...

...Wei Wang wrote: > > On 07/11/2018 05:21 PM, Michal Hocko wrote: > > > On Tue 10-07-18 18:44:34, Linus Torvalds wrote: > > > [...] > > > > That was what I tried to encourage with actually removing the > > > > pages form the page list. That would be an _incremental_ > > > > interface. You can remove MAX_ORDER-1 pages one by one (or a > > > > hundred at a time), and mark them free for ballooning that way. > > > > And if you still feel you have tons of free memory, just continue > removing more pages from the free list. &gt...

...e one. Some moves are _speculative_. Next move after that is totally dependent on up-to-date liveness information. If/when we decide to do proper _global_ instruction scheduling, we will need this mechanism to perform flawlessly. On a low level, if I start with a correct set of live-ins, I can do _incremental_ liveness update pretty much always (I do skip some nasty corner cases for parallel semantics). My current problem is that I had to implement this whole incremental liveness analysis in my late pass... (because LIS does not work that late)... which is something I do not want to carry forward for too...

NAK. On Tue, Jul 10, 2018 at 2:56 AM Wei Wang <wei.w.wang at intel.com> wrote: > > + > + buf_page = list_first_entry_or_null(pages, struct page, lru); > + if (!buf_page) > + return -EINVAL; > + buf = (__le64 *)page_address(buf_page); Stop this garbage. Why the hell would you pass in some crazy "liost of pages" that uses that lru

NAK. On Tue, Jul 10, 2018 at 2:56 AM Wei Wang <wei.w.wang at intel.com> wrote: > > + > + buf_page = list_first_entry_or_null(pages, struct page, lru); > + if (!buf_page) > + return -EINVAL; > + buf = (__le64 *)page_address(buf_page); Stop this garbage. Why the hell would you pass in some crazy "liost of pages" that uses that lru

On Tue 10-07-18 18:44:34, Linus Torvalds wrote: [...] > That was what I tried to encourage with actually removing the pages > form the page list. That would be an _incremental_ interface. You can > remove MAX_ORDER-1 pages one by one (or a hundred at a time), and mark > them free for ballooning that way. And if you still feel you have tons > of free memory, just continue removing more pages from the free list. We already have an interface for that. alloc_pages(G...

On Wed 11-07-18 18:52:45, Wei Wang wrote: > On 07/11/2018 05:21 PM, Michal Hocko wrote: > > On Tue 10-07-18 18:44:34, Linus Torvalds wrote: > > [...] > > > That was what I tried to encourage with actually removing the pages > > > form the page list. That would be an _incremental_ interface. You can > > > remove MAX_ORDER-1 pages one by one (or a hundred at a time), and mark > > > them free for ballooning that way. And if you still feel you have tons > > > of free memory, just continue removing more pages from the free list. > > We already ha...

On Feb 4, 2013, at 3:44 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Seems like an easy solution for this case... But let me ask you a more > general question. > The reason I kept on hanging on to the MBB->splice was (probably outdated) > assumption that it will one day properly update liveness for instructions it > moves... That is a serious matter

Jakob, Seems like an easy solution for this case... But let me ask you a more general question. The reason I kept on hanging on to the MBB->splice was (probably outdated) assumption that it will one day properly update liveness for instructions it moves... That is a serious matter for what I am trying to do (global code motion in presence of bundles). What is the current thinking? Will