Hi,
This is set of patches almost lost in one of my older branches. I decided to
clean them and post given the work on newer MMU.
Thx,
-Vineet
Vineet Gupta (6):
ARCv2: mm: TLB Miss optim: SMP builds can cache pgd pointer in mmu
scratch reg
ARCv2: mm: TLB Miss optim: Use double world
On 9/3/19 8:08 AM, Masahiro Yamada wrote:
>> So if you could please split out the Wmaybe-uninitialized change
> I could not understand your request.
>
> I added 'imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED'
> for CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3.
>
> I cannot split it out. Otherwise, you will se
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
than hardwiring to -O3.
So if you could please split out the Wmaybe-uninitialized change
Acked-by: Vineet Gupta
> Signed-off-by: Masahiro Yamada
> ---
>
> Makefile | 10 ++
> arch/arc/Makefile | 8
> arc
On 8/29/19 8:05 AM, Gustavo A. R. Silva wrote:
> No. This is a different one. Notice that the subject lines differ by one
> letter.
Umm, indeed I thought I'd already merged it.
Now added, will show up in linux-next after rc7
-Vineet
___
linux-snps-arc
Hi Linus,
Late pull request for ARC as I was off to land of monsoons.
Please pull.
P.S. Using my private email (also on pgp key) due to some interim IT email
shenanigans being sorted out.
Thx,
-Vineet
->
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linu
On 7/18/19 6:20 AM, Eugeniy Paltsev wrote:
> Implement jump label patching for ARC. Jump labels provide
> an interface to generate dynamic branches using
> self-modifying code.
>
> This allows us to implement conditional branches where
> changing branch direction is expensive but branch selection
On 8/6/19 1:02 AM, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: haps_hs_defconfig arc):
>
> arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> arc
On 7/16/19 1:51 PM, Alexey Brodkin wrote:
> As per PRM "kflag" instruction doesn't change state of
> DE-flag ("Delayed branch is pending") and U-flag ("User mode")
> in STATUS32 register so let's not act as if we can affect those bits.
I understand the motivation and indeed bits not writable by kf
On 7/17/19 8:09 AM, Eugeniy Paltsev wrote:
>>> +/* Halt system on fatal error to make debug easier */
>>> +#define arc_jl_fatal(format...)
>>> \
>>> +({ \
>>> + pr_err(JUMPLABEL_ERR format)
On 7/16/19 1:22 PM, Vineet Gupta wrote:
> Hi Linus,
>
> Bunch of changes for ARC, some long due, for the new release. Please pull.
>
> Thx,
> -Vineet
Sorry almost forgot, you would run into some merge conflict due to collisions
between do_page_fault() rework and force_si
ann (1):
ARC: hide unused function unw_hdr_alloc
Eugeniy Paltsev (2):
ARC: [plat-hsdk]: enable DW SPI controller
ARC: [plat-hsdk]: Enable AXI DW DMAC in defconfig
Vineet Gupta (14):
ARC: mm: do_page_fault refactor #1: remove label @good_area
ARC: mm: do_page_fa
On 6/18/19 9:16 AM, Vineet Gupta wrote:
> On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
>> Implement jump label patching for ARC. Jump labels provide
>> an interface to generate dynamic branches using
>> self-modifying code.
>>
>> This allows us to implement condi
On 7/3/19 6:39 AM, Arnd Bergmann wrote:
> As kernelci.org reports,
Curious, how are you getting these reports ? I want to see as well.
> this function is not used in
> vdk_hs38_defconfig:
>
> arch/arc/kernel/unwind.c:188:14: warning: 'unw_hdr_alloc' defined but not
> used [-Wunused-function]
>
On 5/31/19 1:21 AM, Peter Zijlstra wrote:
> On Thu, May 30, 2019 at 11:22:42AM -0700, Vineet Gupta wrote:
>> Hi Peter,
>>
>> Had an interesting lunch time discussion with our hardware architects
>> pertinent to
>> "minimal guarantees expected of
Hi Linus,
Please pull some fixes for ARC.
Thx,
-Vineet
->
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git
On 6/18/19 9:16 AM, Vineet Gupta wrote:
> On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
>> Implement jump label patching for ARC. Jump labels provide
>> an interface to generate dynamic branches using
>> self-modifying code.
>>
>> This allows us to implement condi
On 6/20/19 12:52 AM, Peter Zijlstra wrote:
>
> With everything little endian, everything seems just fine. If you load
> the first 2 byte at offset 0, you get the first 2 bytes of the
> instruction.
It has to do with the instruction encoding scheme and what part of instruction
has
the major opcod
On 6/20/19 12:01 AM, Peter Zijlstra wrote:
>
> In particular we do not need the alignment.
>
> So what the x86 code does is:
>
> - overwrite the first byte of the instruction with a single byte trap
>instruction
>
> - machine wide IPI which synchronizes I$
>
> At this point, any CPU tha
On 6/19/19 1:12 AM, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 04:16:20PM +0000, Vineet Gupta wrote:
>
>>> +/*
>>> + * To make atomic update of patched instruction available we need to
>>> guarantee
>>> + * that this instruction doesn't cros
On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
> Implement jump label patching for ARC. Jump labels provide
> an interface to generate dynamic branches using
> self-modifying code.
>
> This allows us to implement conditional branches where
> changing branch direction is expensive but branch selection
>
+CC Masami San, Eugeniy
On 6/13/19 10:57 AM, Vineet Gupta wrote:
> On 6/13/19 3:07 AM, Anshuman Khandual wrote:
>> Questions:
>>
>> AFAICT there is no equivalent of erstwhile notify_page_fault() during page
>> fault handling in arc and mips archs which can call this
On 6/13/19 11:14 AM, Eugeniy Paltsev wrote:
> BTW:
> there is discussion in Linux ML about implementation of static calls.
> The idea is to patch immediate operand in jump instruction instead of using
> function pointers to optimize hot code.
> @vineet I bet you'll like this :)
>
> Current v3 patc
+CC Masami San
On 6/13/19 3:07 AM, Anshuman Khandual wrote:
> Questions:
>
> AFAICT there is no equivalent of erstwhile notify_page_fault() during page
> fault handling in arc and mips archs which can call this generic function.
> Please let me know if that is not the case.
For ARC do_page_fault
On 6/12/19 4:17 AM, Masahiro Yamada wrote:
> Hi.
>
> On Tue, Jun 4, 2019 at 2:49 AM Alexey Brodkin
> wrote:
>>
>> Hi Vineet,
>>
>>> -Original Message-
>>> From: Vineet Gupta
>>> Sent: Monday, June 3, 2019 7:25 PM
>>> T
s, not so
much
for 2 or 4 bytes: every use case is different.
>
> Best regards,
> Cupertino
>
>
> On Tue, 2019-06-11 at 18:47 +, Eugeniy Paltsev wrote:
>> Hi Vineet,
>>
>> On Mon, 2019-06-10 at 15:55 +, Vineet Gupta wrote:
>>> On 6/8/
On 6/11/19 11:47 AM, Eugeniy Paltsev wrote:
> Hi Vineet,
>
> On Mon, 2019-06-10 at 15:55 +0000, Vineet Gupta wrote:
>> On 6/8/19 11:21 AM, Eugeniy Paltsev wrote:
>>> Hi Cupertino,
>>>
>>> I tried to use ".bundle_align_mode" direc
On 6/8/19 11:21 AM, Eugeniy Paltsev wrote:
> Hi Cupertino,
>
> I tried to use ".bundle_align_mode" directive in ARC assembly, but I got
> following error:
> ->8--
> Assembler messages:
> Error: unknown pseudo-op: `.bundle_align_mode'
> ->8--
my local test setup had that revert to validate this fix.
Signed-off-by: Vineet Gupta
---
arch/arc/kernel/entry-arcv2.S | 55 +++
1 file changed, 8 insertions(+), 47 deletions(-)
diff --git a/arch/arc/kernel/entry-arcv2.S b/arch/arc/kernel/entry-arcv2.
On 4/22/19 11:02 AM, Eugeniy Paltsev wrote:
> Implement jump label patching for ARC. Jump labels provide
> an interface to generate dynamic branches using
> self-modifying code.
>
> This allows us to implement conditional branches where
> changing branch direction is expensive but branch selection
Hi Waldemar,
After test-suite commit 9f079b6353 "(disable complex math)" the math tests build
and I see lot of failures (for the default soft float builds)
test-float-finiteFAIL test-float-finite got 1 expected 0
test-floatFAIL test-float got 1 expected 0
te
On 6/3/19 1:13 PM, Paul E. McKenney wrote:
> On Mon, Jun 03, 2019 at 06:08:35PM +0000, Vineet Gupta wrote:
>> On 5/31/19 1:21 AM, Peter Zijlstra wrote:
>>>> I'm not sure how to interpret "natural alignment" for the case of double
>>>> load/stores on
ess kernel virtual memory
ARC: [plat-hsdk]: enable creg-gpio controller
ARC: [plat-hsdk]: Add support of Vivante GPU
Jose Abreu (2):
ARC: [plat-hsdk]: Add missing multicast filter bins number to GMAC node
ARC: [plat-hsdk]: Add missing FIFO size entry in GMAC node
Vineet Gupta
On 5/31/19 2:41 AM, David Laight wrote:
>> While it seems reasonable form hardware pov to not implement such atomicity
>> by
>> default it seems there's an additional burden on application writers. They
>> could
>> be happily using a lockless algorithm with just a shared flag between 2
>> thread
On 5/31/19 1:21 AM, Peter Zijlstra wrote:
> And I'll stand by my earlier conviction that any architecture that has a
> native u64 (be it a 64bit arch or a 32bit with double-width
> instructions) but has an ABI that allows u32 alignment on them is daft.
Why ? For 64-bit data on 32-bit systems, hard
On 5/31/19 1:21 AM, Peter Zijlstra wrote:
>> I'm not sure how to interpret "natural alignment" for the case of double
>> load/stores on 32-bit systems where the hardware and ABI allow for 4 byte
>> alignment (ARCv2 LDD/STD, ARM LDRD/STRD )
> Natural alignment: !((uintptr_t)ptr % sizeof(*ptr))
>
ll the prefixes it didn't manage to find
> a matching cross-compiler for like that:
> | # ARCH=arc make defconfig
> | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> | *** Default configuration is based on 'nsim_hs_defconfig'
>
> Signed-off-by: Ale
On 5/30/19 11:55 AM, Paul E. McKenney wrote:
>
>> I'm not sure how to interpret "natural alignment" for the case of double
>> load/stores on 32-bit systems where the hardware and ABI allow for 4 byte
>> alignment (ARCv2 LDD/STD, ARM LDRD/STRD )
>>
>> I presume (and the question) that lkmm doesn
Hi Peter,
Had an interesting lunch time discussion with our hardware architects pertinent
to
"minimal guarantees expected of a CPU" section of memory-barriers.txt
| (*) These guarantees apply only to properly aligned and sized scalar
| variables. "Properly sized" currently means variables
target specific optimization/tuning in ARC backend ?
>
> On Thu, 2019-05-16 at 17:37 +, Vineet Gupta wrote:
>> On 5/16/19 10:24 AM, Eugeniy Paltsev wrote:
>>>> +unsigned int write = 0, exec = 0, mask;
>>>
>>> Probably it's better to use &#
On 5/14/19 5:29 PM, Vineet Gupta wrote:
> In case of successful page fault handling, this patch releases mmap_sem
> before updating the perf stat event for major/minor faults. So even
> though the contention reduction is NOT supe rhigh, it is still an
> improvement.
This patch cause
On 5/15/19 8:33 AM, Alexey Brodkin wrote:
> Initial bring-up of the platform was done on FPGA prototype
> where TI's DP83867 PHY was used. And so some specific PHY
> options were added.
>
> Just to confirm this is what we get on FPGA prototype in the bootlog:
> | TI DP83867 stmmac-0:00: attached P
On 5/21/19 10:54 AM, Eugeniy Paltsev wrote:
> HSDK board has built-in Vivante GPU IP which works perfectly fine
> with Etnaviv driver, so let's use it.
>
> Signed-off-by: Eugeniy Paltsev
Added to for-curr.
Thx,
-Vineet
___
linux-snps-arc mailing list
On 5/28/19 2:40 AM, Eugeniy Paltsev wrote:
> HSDK SOC has CREG GPIO controller which can be used to control
> SPI chip select lines.
> Enable it in preparation of enabling SPI peripherals.
>
> Signed-off-by: Eugeniy Paltsev
Added to for-curr
Thx,
-Vineet
___
On 9/16/18 1:47 PM, Alexey Brodkin wrote:
> There's not much sense in doing that because if user or
> his build-system didn't set CROSS_COMPILE we still may
> very well make incorrect guess.
>
> But as it turned out setting CROSS_COMPILE is not as harmless
> as one may think: with recent changes t
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/entry-arcv2.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arc/include/asm/entry-arcv2.h
b/arch/arc/include/asm/entry-arcv2.h
index 3209a6762960..beaf655666cb 100644
--- a/arch/arc/include/asm/entry-arcv2.h
avoids 1 MOV instruction in light of double load/store code
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/entry-arcv2.h | 3 +--
arch/arc/include/asm/entry-compact.h | 4 ++--
arch/arc/kernel/entry.S | 4 ++--
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a
clobbered is much cleaner and
also serves to document the fact.
- Makes EXCEPTION_PROLGUE similar to INTERRUPT_PROLOGUE so easier to
refactor the common parts which is what this series aims to do
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/entry-arcv2.h | 8
arch/arc/
- the motivation was to be remove blatent copy-paste due to hasty support
of CONFIG_ARC_IRQ_NO_AUTOSAVE support
- but with refactoring we could use LDD/STD to greatly optimize the code
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/entry-arcv2.h | 297
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/entry-arcv2.h | 78 ++
1 file changed, 62 insertions(+), 16 deletions(-)
diff --git a/arch/arc/include/asm/entry-arcv2.h
b/arch/arc/include/asm/entry-arcv2.h
index 225e7df2d8ed..1c3520d1fa42 100644
--- a
This was along pending todo item to remove the copy-paste from NO_AUTOSAVE
support as well use LDD/STD instructions for better generated code.
Thx,
-Vineet
Vineet Gupta (5):
ARCv2: entry: comments about hardware auto-save on taken interrupts
ARCv2: entry: push out the Z flag unclobber from
On 5/16/19 10:44 AM, Alexey Brodkin wrote:
>> On 5/16/19 10:24 AM, Eugeniy Paltsev wrote:
+ unsigned int write = 0, exec = 0, mask;
>>> Probably it's better to use 'bool' type for 'write' and 'exec' as we really
>>> use them as a boolean
>> variables.
>>
>> Right those are semantics, but the
On 5/16/19 10:24 AM, Eugeniy Paltsev wrote:
>> +unsigned int write = 0, exec = 0, mask;
> Probably it's better to use 'bool' type for 'write' and 'exec' as we really
> use them as a boolean variables.
Right those are semantics, but the generated code for "bool" is not ideal -
given
it is inh
ch guards entry into perf
stats event update
Cc: Peter Zijlstra
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 20402217d9da..e93ea06c214c 100644
--- a/arch/arc/m
t;8-
#include
#include
int main(int argc, char *argv[])
{
volatile uint32_t temp;
temp = *(uint32_t *)(0x7000);
}
>8-
Cc:
Signed-off-by: Eugeniy Paltsev
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 9 +++---
This is different than the rest of signal handling stuff
No functional change
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 7f211b493170
- up_read
- if !user_mode
- whatever error handling
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index c0a60aeb4abd..0e1a222a97ad 100644
--- a/arch/arc
- single up_read() call vs. 4
- so much easier on eyes
Technically it seems like @bad_area label moved up, but even in old
regime, it was a special case of delivering SIGSEGV unconditionally
which we now do as well, although with checks.
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c
stats update code can now elide "retry" check and additional level of
indentation since all retry handling is done ahead of it already
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 60 +++--
1 file changed, 31 insertions(+), 29
The coding pattern to NOT intialize variables at declaration time but
rather near code which makes us eof them makes it much easier to grok
the overall logic, specially when the init is not simply 0 or 1
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 39
Compiler will do this anyways, still..
No functional change.
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 94d242740ac5..f1175685d914 100644
--- a/arch/arc/mm/fault.c
event user space looping
- reduction in mmap_sem hold times
Also this could have been 1 single patch but this is tricky part of mm
handling so better done as bite sized pieces to track down any regressions
Eugeniy Paltsev (1):
ARC: mm: SIGSEGV userspace trying to access kernel virtual memory
Vi
Invert the condition for stack expansion.
No functional change
Signed-off-by: Vineet Gupta
---
arch/arc/mm/fault.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 6836095251ed..94d242740ac5 100644
--- a/arch/arc/mm
use @no_context label, removing the need for
> @bad_area_nosemaphore and untangling the code mess a bit.
Say ... "And while we are here, remove @bad_area_nosemaphore label, untangling
the
code mess a bit"
>
> Cc: # 4.20+
Why just 4.20, this needs to go back as far as possible
handle_kernel_vaddr_fault(address);
> if (unlikely(ret))
> goto bad_area_nosemaphore;
LGTM. However I have an old patch as part of do_page_fault cleanup - the idea is
to delete one label, but hopefully it will fix ur case too - can u please give
it
a spin with u
On 5/8/19 8:23 AM, Alexey Brodkin wrote:
> Based on preprocessor defines we determine which type of ARC core
> we're targeting and set slibdir accordingly so that on installation
> of libraries to sysroot libs for different ARC cores end up in different
> locations which match ARC Linux multilib sp
On 5/2/19 9:41 AM, Arnaldo Carvalho de Melo wrote:
>> While this takes care of immediate issues, for the long term, are you open
>> to idea
>> of removing the header duplicity.
>
> In the beginning we used the kernel headers directly, then, acting on
> advice/complaints from Linus about tooling br
On 4/30/19 8:12 PM, Rich Felker wrote:
>>> What are you trying to achieve? I was just CC'd and I'm missing the
>>> context.
>>
>> Sorry I added you as a subject matter expert but didn't provide enough
>> context.
>>
>> The original issue [1] was perf failing to build on ARC due to perf tools
>> n
On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>>
>>> Auto-detecting system features:
>>> ... dwarf: [ OFF ]
>>> ...dwarf_getlocations: [ OFF ]
>>> ... glibc: [ on ]
>>
>> Not related to current issue, this run uses a uClibc toolcha
On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
>> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
>>>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
>>>> missed all t
.
^
| bpf.c: In function 'sys_bpf':
| bpf.c:66:17: error: '__NR_bpf' undeclared (first use in this function)
| return syscall(__NR_bpf, cmd, attr, size);
| ^~~~
| sys_bpf
Signed-off-by: Vineet Gupta
---
v1 -> v2
- Only add syscall nr for ARC, as
; Signed-off-by: Jose Abreu
> Cc: Joao Pinto
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: Vineet Gupta
> ---
> arch/arc/boot/dts/hsdk.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> index 69bc1c9e8e
c value, but i think a better fix
is to use the asm-generic uapi value applicable to ARC as well as any new
arch (hopefully we don't add an old existing arch here). Otherwise I can
just add __arc__
Signed-off-by: Vineet Gupta
---
tools/lib/bpf/bpf.c | 5 -
1 file changed, 4 insertion
On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
>> missed all the other architectures changed in c8ce48f06503 and the
>> related commits.
> Right, I have a patch copying the missing headers, and that fixed the
> build with the
in memset if line size !64
- avoid panic if PAE and IOC
Eugeniy Paltsev (1):
ARC: memset: fix build with L1_CACHE_SHIFT != 6
Vineet Gupta (2):
ARC: PAE40: don't panic and instead turn off hw ioc
ARC: [hsdk]
On 4/30/19 10:04 AM, Rich Felker wrote:
> On Tue, Apr 30, 2019 at 03:53:18PM +0000, Vineet Gupta wrote:
>> On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>>>> Auto-detecting system features:
>>>>> ... dwarf: [ OFF ]
>>
On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>> Auto-detecting system features:
>>> ... dwarf: [ OFF ]
>>> ...dwarf_getlocations: [ OFF ]
>>> ... glibc: [ on ]
>> Not related to current issue, this run uses a uClibc toolchain and
o de Melo escreveu:
>>>> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
>>>>> When building perf for ARC (v5.1-rc2) I get the following
>>>>
>>>>> | In file included from bench/futex-hash.c:26:
>>>>> | bench/futex.
On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
>> A quick fix for ARC will be to create our own version but I presume all
>> existing
>> arches using generic syscall abi are affected. Thoughts ? In lack of ideas
>> I'll
>> send out a patch for ARC.
>>
>> P.S. Why do we need the unistd.h dupl
On 4/25/19 2:48 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
>>> When building perf for ARC (v5.1-rc2) I get the following
>>
>
Hi,
When building perf for ARC (v5.1-rc2) I get the following
| In file included from bench/futex-hash.c:26:
| bench/futex.h: In function 'futex_wait':
| bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this
function);
git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 (
On 4/16/19 10:10 AM, Eugeniy Paltsev wrote:
> One step to "build once run anywhere"
This is what I'm afraid is going to happen. We will slowly sneak this into
defconfigs and this will become the default. Occasional need for verification
doesn't necessarily need this complexity to be maintained. No
On 4/16/19 10:10 AM, Eugeniy Paltsev wrote:
> ARC kernel code assumes that all cores have same cache config
> but as of today we check cache configuration only on master CPU.
> Fix that and check cache configuration on each CPU.
What is broken ? With current hardware it is impossible to have a SMP
On 4/1/19 11:43 AM, Eugeniy Paltsev wrote:
> Tweak generic node topology in case of CONFIG_HIGHMEM enabled to
> prioritize allocations from ZONE_HIGHMEM to avoid ZONE_NORMAL
> pressure.
Can you explain the "pressure" part a bit more concretely - as in when did you
saw
crashes, oom, yadi yada
To propagate a fix for gcc bug 88409 [1] in ARC specific code
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89877
Signed-off-by: Vineet Gupta
---
ChangeLog | 4
stdlib/longlong.h | 6 --
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
On 4/3/19 2:53 AM, Claudiu Zissulescu wrote:
> Pushed, thank you for your contribution,
> Claudiu
Thx, can this be backported to gcc-8-stable please which is what glibc folks use
for testing !
-Vineet
>
> On Tue, Apr 2, 2019 at 9:27 PM Vineet Gupta
> wrote:
>> simple t
On 4/3/19 9:34 AM, Eugeniy Paltsev wrote:
>> -reg = <0x8000 0x4000>; /* 1 GiB */
>> +reg = <0x0 0x8000 0x0 0x4000>; /* 1 GB lowmem */
>> +/* 0x1 0x 0x0 0x4000>; 1 GB highmem */
> Could you please get rid of comment with refer
beyond 4GB physical
address space
Signed-off-by: Vineet Gupta
---
arch/arc/boot/dts/hsdk.dts | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index 69bc1c9e8e50..7425bb0f2d1b 100644
--- a/arch/arc/boo
04
|printf("%d\n", (size_t)secs);
| }
The printf eventually called into glibc stdlib/divrem.c:__mpn_divrem()
which uses the __arc__ specific inline asm macros from longlong.h which
were causing miscompilation.
include/
2019-03-28 Vineet Gupta
PR 89877
* longlong.h
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
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_
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
ple byte copies swap is implemented
> without them, an "optimized" custom swap function is now
> a waste of time as well as code.
>
> Signed-off-by: Andrey Abramov
> Reviewed by: George Spelvin
>
Acked-by: Vineet Gupta
Thx,
-Vineet
ff-by: Vineet Gupta
---
arch/arc/mm/cache.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 4135abec3fb0..63e6e6504699 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -113,10 +1
On 3/28/19 5:07 PM, Marc Glisse wrote:
> On Thu, 28 Mar 2019, Vineet Gupta wrote:
>
>> simple test such as below was failing.
>>
>> | void main(int argc, char *argv[])
>> | {
>> |size_t total_time = 115424; // expected 115.424
>
04
|printf("%d\n", (size_t)secs);
| }
The printf eventually called into glibc stdlib/divrem.c:__mpn_divrem()
which uses the __arc__ specific inline asm macros from longlong.h which
were causing miscompilation.
include/
2019-03-28 Vineet Gupta
PR 89877
* longlong.h
On 3/20/19 3:48 PM, Petr Vorel wrote:
>> +ifndef HAVE_LIBAIO_H
>> +FILTER_OUT_DIRS += aio
>> +endif
> This is IMHO wrong, as all files using libaio.h are guarded with
> TST_TEST_TCONF().
You're right. It seems this ltp tree of mine had stray aio1 and aio2 dir in the
io/aio which was actually t
On 3/21/19 5:06 AM, Petr Vorel wrote:
> Hi Vineet,
>
>> On 3/20/19 3:37 PM, Petr Vorel wrote:
+# controllers/cpuset/cpuset_lib/libcpuset.c uses fts
+# which may not be available/configured in the libc build
+ifndef HAVE_FTS_H
+FILTER_OUT_DIRS += cpuset
+endif
>>> Have you
Hi Petr,
On 3/20/19 3:37 PM, Petr Vorel wrote:
>
>> +# controllers/cpuset/cpuset_lib/libcpuset.c uses fts
>> +# which may not be available/configured in the libc build
>> +ifndef HAVE_FTS_H
>> +FILTER_OUT_DIRS += cpuset
>> +endif
> Have you tested it?
Absolutely. I verified again. With this
801 - 900 of 1956 matches
Mail list logo
