Tweak generic node topology in case of CONFIG_HIGHMEM enabled to
prioritize allocations from ZONE_HIGHMEM to avoid ZONE_NORMAL
pressure.
Signed-off-by: Eugeniy Paltsev
---
Tested on both NSIM and HSDK (require memory apertures remmaping and
device tree patching)
arch/arc/include/asm/Kbuild
On 4/1/19 11:14 AM, Andrey Abramov wrote:
> George Spelvin wrote "So how about *deleting* the parameter instead?
> That simplifies everything.", and he is right,
> so I am just going to completely remove it.
>
> Any objections?
LGTM.
___
linux-snps-arc
01.04.2019, 21:02, "Vineet Gupta" :
> On 4/1/19 7:46 AM, David Laight wrote:
>> From: gre...@linuxfoundation.org
>>> Sent: 31 March 2019 11:54
>> ...
>>> Yes, "int" is a very nice variable for "size", you need to explain why
>>> it is better to use size_t here please.
>> Actually, on x86_64 y
On Mon, 2019-04-01 at 11:08 -0700, Vineet Gupta wrote:
> On 4/1/19 11:04 AM, Eugeniy Paltsev wrote:
> > > + if (IS_ENABLED(CONFIG_HIGHMEM) || is_pae40_enabled())
> >
> > As for today PAE40 couldn't be enabled without HIGHMEM for ARC, so probably
> > we can
> > simplify this to
> >
> > --
Commit 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver")
added an incorrect file pattern. Fix it.
Reported-by: Joe Perches
Signed-off-by: Eugeniy Paltsev
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3e5a5d263f29..be82
On 4/1/19 11:04 AM, Eugeniy Paltsev wrote:
>> +if (IS_ENABLED(CONFIG_HIGHMEM) || is_pae40_enabled())
> As for today PAE40 couldn't be enabled without HIGHMEM for ARC, so probably
> we can
> simplify this to
>
> ->8--
> if (IS_
Hi Vineet,
On Fri, 2019-03-29 at 13:45 -0700, Vineet Gupta wrote:
> HSDK currently panics when built for HIGHMEM/ARC_HAS_PAE40 because ioc
> is enabled with default which doesn't for the 2 non contiguous memory
> nodes.
>
> So get PAE working with ioc disabled instead
>
> Tested with !PAE40 by f
On 4/1/19 7:46 AM, David Laight wrote:
> From: gre...@linuxfoundation.org
>> Sent: 31 March 2019 11:54
> ...
>> Yes, "int" is a very nice variable for "size", you need to explain why
>> it is better to use size_t here please.
> Actually, on x86_64 you probably want 'unsigned int' to avoid the
> com
On 3/31/19 11:31 AM, Andrey Abramov wrote:
> Replace swap_eh_frame_hdr_table_entries with built-in one, because
> swap_eh_frame_hdr_table_entries does a simple byte to byte swap.
>
> Since Spectre mitigations have made indirect function calls more
> expensive, and the default simple byte copies swa
From: gre...@linuxfoundation.org
> Sent: 31 March 2019 11:54
...
> Yes, "int" is a very nice variable for "size", you need to explain why
> it is better to use size_t here please.
Actually, on x86_64 you probably want 'unsigned int' to avoid the
compiler having to generate a sign-extending registe
From: "Steven Rostedt (VMware)"
After removing the start and count arguments of syscall_get_arguments() it
seems reasonable to remove them from syscall_set_arguments(). Note, as of
today, there are no users of syscall_set_arguments(). But we are told that
there will be soon. But for now, at least
From: "Steven Rostedt (Red Hat)"
At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
function call syscall_get_arguments() implemented in x86 was horribly
written and not optimized for the standard case of passing in 0 and 6 for
the starting index and the number of system ca
Andrey Abramov writes:
> Replace relaswap with built-in one, because relaswap
> does a simple byte to byte swap.
I replied to v1 with an ack, which stands, this is just a clarification.
> Since Spectre mitigations have made indirect function calls more
> expensive, and the default simple byte co
On Mon, Apr 01, 2019 at 09:56:07AM +, George Spelvin wrote:
> On Mon, 1 Apr 2019 at 12:35:55 +0300, Andy Shevchenko wrote:
> > Hmm... If (*swap)() is called recursively it means the change might increase
> > stack usage on 64-bit platforms.
> >
> > Am I missing something?
>
> Under what conce
On Mon, 1 Apr 2019 at 12:35:55 +0300, Andy Shevchenko wrote:
> Hmm... If (*swap)() is called recursively it means the change might increase
> stack usage on 64-bit platforms.
>
> Am I missing something?
Under what conceivable circumstance would someone write a recursive
(*swap)() function?
You'r
On Sun, Mar 31, 2019 at 09:52:50PM +0300, Andrey Abramov wrote:
> Replace int type with size_t type of the size argument
> in the swap function, also affect all its dependencies.
>
> It's always been weird that sort() takes a size_t element size,
> but passes an int size to (*swap)(). Not a bug be
16 matches
Mail list logo
