search for: max_order

...maximum allowed sample frequency [Hz] */ -#define RMS_WINDOW_TIME 0.050 /* Time slice size [s] */ -#define STEPS_per_dB 100. /* Table entries per dB */ -#define MAX_dB 120. /* Table entries for 0...MAX_dB (normal max. values are 70...80 dB) */ - -#define MAX_ORDER (BUTTER_ORDER > YULE_ORDER ? BUTTER_ORDER : YULE_ORDER) -/* [JEC] the following was originally #defined as: - * (size_t) (MAX_SAMP_FREQ * RMS_WINDOW_TIME) - * but that seemed to fail to take into account the ceil() part of the - * sampleWindow calculation in ResetSampleFrequency(...

The replay gain code has dos line endings in CVS, which causes problems for the Sun compiler, among others. Attached is a patch for the lazy, but it's probably easier to fix locally and commit. -r

On Fri, Dec 16, 2016 at 01:12:21AM +0000, Li, Liang Z wrote: > There still exist the case if the MAX_ORDER is configured to a large value, e.g. 36 for a system > with huge amount of memory, then there is only 28 bits left for the pfn, which is not enough. Not related to the balloon but how would it help to set MAX_ORDER to 36? What the MAX_ORDER affects is that you won't be able to ask the kern...

On Fri, Dec 16, 2016 at 01:12:21AM +0000, Li, Liang Z wrote: > There still exist the case if the MAX_ORDER is configured to a large value, e.g. 36 for a system > with huge amount of memory, then there is only 28 bits left for the pfn, which is not enough. Not related to the balloon but how would it help to set MAX_ORDER to 36? What the MAX_ORDER affects is that you won't be able to ask the kern...

...; > >> The only real question IMNHO is whether we should do a power-of-2 or a > >> length. But, if we have 12 bits, then the argument for doing length is pretty > >> strong. We don't need anywhere near 12 bits if doing power-of-2. > > > > Just found the MAX_ORDER should be limited to 12 if use length instead of order, > > If the MAX_ORDER is configured to a value bigger than 12, it will make things more > > complex to handle this case. > > > > If use order, we need to break a large memory range whose length is not the power of 2 in...

...; > >> The only real question IMNHO is whether we should do a power-of-2 or a > >> length. But, if we have 12 bits, then the argument for doing length is pretty > >> strong. We don't need anywhere near 12 bits if doing power-of-2. > > > > Just found the MAX_ORDER should be limited to 12 if use length instead of order, > > If the MAX_ORDER is configured to a value bigger than 12, it will make things more > > complex to handle this case. > > > > If use order, we need to break a large memory range whose length is not the power of 2 in...

On Tue, Jul 10, 2018 at 6:24 PM Wei Wang <wei.w.wang at intel.com> wrote: > > We only get addresses of the "MAX_ORDER-1" blocks into the array. The > max size of the array that could be allocated by kmalloc is > KMALLOC_MAX_SIZE (i.e. 4MB on x86). With that max array, we could load > "4MB / sizeof(u64)" addresses of "MAX_ORDER-1" blocks, that is, 2TB free > memory at most. We t...

On Tue, Jul 10, 2018 at 6:24 PM Wei Wang <wei.w.wang at intel.com> wrote: > > We only get addresses of the "MAX_ORDER-1" blocks into the array. The > max size of the array that could be allocated by kmalloc is > KMALLOC_MAX_SIZE (i.e. 4MB on x86). With that max array, we could load > "4MB / sizeof(u64)" addresses of "MAX_ORDER-1" blocks, that is, 2TB free > memory at most. We t...

This patch adds a per-node bucket to the heap structure in Xen. During heap initialization the patch determines which bucket to place the memory. We reserve guard pages between node boundaries in the case that said boundary isn''t already guarded by the MAX_ORDER boundary to prevent the buddy allocator from merging pages between nodes. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com diffstat output: common/page_alloc.c | 211 +++++++++++++++++++++++++++++++++++++++++-------...

...u64 *array = page_address(page); int nr = PAGE_SIZE / sizeof(u64); and now you pass that array in to the thing. None of this completely insane crazy crap interfaces. Plus, I still haven't heard an explanation for why you want so many pages in the first place, and why you want anything but MAX_ORDER-1. So no. This kind of unnecessarily complex code with completely insane calling interfaces does not make it into the VM layer. Maybe that crazy "let's pass a chain of pages that uses the lru list" makes sense to the virtio-balloon code. But you need to understand that it makes ZERO...

...u64 *array = page_address(page); int nr = PAGE_SIZE / sizeof(u64); and now you pass that array in to the thing. None of this completely insane crazy crap interfaces. Plus, I still haven't heard an explanation for why you want so many pages in the first place, and why you want anything but MAX_ORDER-1. So no. This kind of unnecessarily complex code with completely insane calling interfaces does not make it into the VM layer. Maybe that crazy "let's pass a chain of pages that uses the lru list" makes sense to the virtio-balloon code. But you need to understand that it makes ZERO...

...> continue; >>> Can we directly use for_each_populated_zone(zone) here? > yes, my example couldn't because I was still assuming per-node API > >>>> spin_lock_irqsave(&zone->lock, flags); >>>> for (order = min_order; order < MAX_ORDER; ++order) { >>> >>> This appears to be covered by for_each_migratetype_order(order, mt) below. > yes but > #define for_each_migratetype_order(order, type) \ > for (order = 0; order < MAX_ORDER; order++) \ > for (type = 0; type < MIGRATE_TYPES; type++) > &gt...

...> continue; >>> Can we directly use for_each_populated_zone(zone) here? > yes, my example couldn't because I was still assuming per-node API > >>>> spin_lock_irqsave(&zone->lock, flags); >>>> for (order = min_order; order < MAX_ORDER; ++order) { >>> >>> This appears to be covered by for_each_migratetype_order(order, mt) below. > yes but > #define for_each_migratetype_order(order, type) \ > for (order = 0; order < MAX_ORDER; order++) \ > for (type = 0; type < MIGRATE_TYPES; type++) > &gt...

...= &pgdat->node_zones[i]; >> >> if (!populated_zone(zone)) >> continue; > > Can we directly use for_each_populated_zone(zone) here? > > >> spin_lock_irqsave(&zone->lock, flags); >> for (order = min_order; order < MAX_ORDER; ++order) { > > > This appears to be covered by for_each_migratetype_order(order, mt) > below. > > >> struct free_area *free_area = &zone->free_area[order]; >> enum migratetype mt; >> struct page *page; >> >&gt...

...= &pgdat->node_zones[i]; >> >> if (!populated_zone(zone)) >> continue; > > Can we directly use for_each_populated_zone(zone) here? > > >> spin_lock_irqsave(&zone->lock, flags); >> for (order = min_order; order < MAX_ORDER; ++order) { > > > This appears to be covered by for_each_migratetype_order(order, mt) > below. > > >> struct free_area *free_area = &zone->free_area[order]; >> enum migratetype mt; >> struct page *page; >> >&gt...

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 that. alloc_pages(GFP_NOWAIT, MAX_ORDER -1). &gt...

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 that. alloc_pages(GFP_NOWAIT, MAX_ORDER -1). &gt...

On Wed, Jul 11, 2018 at 2:21 AM Michal Hocko <mhocko at kernel.org> wrote: > > We already have an interface for that. alloc_pages(GFP_NOWAIT, MAX_ORDER -1). > So why do we need any array based interface? That was actually my original argument in the original thread - that the only new interface people might want is one that just tells how many of those MAX_ORDER-1 pages there are. See the thread in v33 with the subject "[PATCH v33 1/4...

On Wed, Jul 11, 2018 at 2:21 AM Michal Hocko <mhocko at kernel.org> wrote: > > We already have an interface for that. alloc_pages(GFP_NOWAIT, MAX_ORDER -1). > So why do we need any array based interface? That was actually my original argument in the original thread - that the only new interface people might want is one that just tells how many of those MAX_ORDER-1 pages there are. See the thread in v33 with the subject "[PATCH v33 1/4...

...consensus is that the bitmap needs to go. > > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of order, If the MAX_ORDER is configured to a value bigger than 12, it will make things more complex to handle this case. If use order, we need to break a large memory range whose length is not the power of 2 into several small ranges, it also make th...