> On 11/04/2020 6:02 PM Mike Rapoport wrote:
>
> Yes, this will work. The processes that share the memfd_secret file
> descriptor will have access to the same memory pages, pretty much like
> with shared memory.
Perfect!
Acked-by: Hagen Paul Pfeifer
Thank you for the effort M
> On 11/03/2020 5:30 PM Mike Rapoport wrote:
>
> > > As long as the task share the file descriptor, they can share the
> > > secretmem pages, pretty much like normal memfd.
> >
> > Including process_vm_readv() and process_vm_writev()? Let's take a
> > hypothetical
> > "dbus-daemon-secure"
> On 11/02/2020 4:40 PM Mike Rapoport wrote:
> > Isn't memfd_secret currently *unnecessarily* designed to be a "one task
> > feature"? memfd_secret fulfills exactly two (generic) features:
> >
> > - address space isolation from kernel (aka SECRET_EXCLUSIVE, not in kernel's
> > direct map) -
* Mike Rapoport | 2020-09-24 16:28:58 [+0300]:
>This is an implementation of "secret" mappings backed by a file descriptor.
>I've dropped the boot time reservation patch for now as it is not strictly
>required for the basic usage and can be easily added later either with or
>without CMA.
Isn't
e garbage for Python2 and Python3
as well as no bytearray type Python3!
Tested-by: Hagen Paul Pfeifer
Thank you Jiri!
Probably this patch should be applied on stable too!? Not sure when the
problem was introduced.
Hagen
>jirka
>
>
>---
>diff --git a/tools/perf/util/print_bi
Short addendum: even under python2 not everything is perfect. It seems that
the "comm-name-memory-reuse" problem is a general problem - for python3 and
python2.
In the following example the prev_comm name should be chrome only, but is
"chromesandbox", common_comm is correctly "chrome". I believe
Hallo Jiri, Arnaldo,
after updating Debian (probably with the advent of Python 3.8.5, guessing)
I get a wired behavior with python scripting. The error is that the python type
for prev_comm and next_comm are not strings anymore, rather bytearrays. Which
are incompatible types and scripts will not
> On 09/23/2020 2:31 PM Arnaldo Carvalho de Melo wrote:
>
> Didn't apply here, I did it by hand, please check, probably some
> indentation artifact.
Probably you missed patch one of the patchset - the autopep8 formatting
one for the lock contention script?
> Thanks for the patch!
You are
avg ns [max:
24323998 ns, min 338 ns]
Signed-off-by: Hagen Paul Pfeifer
Cc: Arnaldo Carvalho de Melo
---
v2: nanosecond, not microseconds
tools/perf/scripts/python/futex-contention.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/scripts/python/futex
10 years leaves its mark! Python has evolved and so has its style guide.
Even with vim it is getting hard to follow the no longer valid
guidelines (spaces vs. tabs).
Autopep8 this code to modernize it!
Signed-off-by: Hagen Paul Pfeifer
Cc: Arnaldo Carvalho de Melo
---
tools/perf/scripts
avg ns [max:
24323998 us, min 338 us]
Signed-off-by: Hagen Paul Pfeifer
Cc: Arnaldo Carvalho de Melo
---
tools/perf/scripts/python/futex-contention.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/scripts/python/futex-contention.py
b/tools/perf/scripts/python
* Tomer Barletz | 2015-08-02 03:36:52 [-0700]:
>With gcc 5.1 I get:
>warning: switch condition has boolean value [-Wswitch-bool]
>
>Signed-off-by: Tomer Barletz
>---
> drivers/mtd/mtd_blkdevs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/mtd/mtd_blkdevs.c
* Tomer Barletz | 2015-08-02 03:36:52 [-0700]:
With gcc 5.1 I get:
warning: switch condition has boolean value [-Wswitch-bool]
Signed-off-by: Tomer Barletz barl...@gmail.com
---
drivers/mtd/mtd_blkdevs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
> On July 16, 2015 at 9:23 PM Joe Perches wrote:
>
> It might be useful to have these performance impacting
> changes guarded by something like CONFIG_CC_OPTIMIZE_FOR_SIZE
> with another static __always_inline __ and a function &
> EXPORT_SYMBOL or just a static inline so that where code size
>
On July 16, 2015 at 9:23 PM Joe Perches j...@perches.com wrote:
It might be useful to have these performance impacting
changes guarded by something like CONFIG_CC_OPTIMIZE_FOR_SIZE
with another static __always_inline __func and a function
EXPORT_SYMBOL or just a static inline so that where
> On July 13, 2015 at 11:06 PM Denys Vlasenko
> wrote:
>
> Not *your* way.
> I meant that I'll send patches to Ingo - I see that he agrees that
> this worth fixing instead of waiting for a better compiler.
Yeah, do it. Sorry it was not my intention to prevent you to fix this -
not at all. Go on,
> On July 13, 2015 at 8:27 PM Denys Vlasenko
> wrote:
> > So I think the original patch makes sense (and I already applied it),
> > we want known-simple and performance critical methods (such as atomic
> > ops) always inlined.
>
> I will send more such force-inlining patches your way then.
On July 13, 2015 at 8:27 PM Denys Vlasenko vda.li...@googlemail.com
wrote:
So I think the original patch makes sense (and I already applied it),
we want known-simple and performance critical methods (such as atomic
ops) always inlined.
I will send more such force-inlining patches your
On July 13, 2015 at 11:06 PM Denys Vlasenko vda.li...@googlemail.com
wrote:
Not *your* way.
I meant that I'll send patches to Ingo - I see that he agrees that
this worth fixing instead of waiting for a better compiler.
Yeah, do it. Sorry it was not my intention to prevent you to fix this -
* Andrew Morton | 2015-05-11 15:19:13 [-0700]:
>Presumably Hagen didn't see the issue with spinlock functions. I
>wonder why not.
I think it is a compiler version thing. Not sure why I didn't see it.
>I suppose we should get both these consolidated into a coherent whole.
+1 (let wait for a
* Denys Vlasenko | 2015-05-08 12:26:02 [+0200]:
[snip]
>With both gcc 4.7.2 and 4.9.2, sometimes gcc mysteriously doesn't inline
>This patch fixes this for x86 atomic ops via s/inline/__always_inline/.
>This decreases allyesconfig kernel by about 25k:
>
>text data bss dec
* Denys Vlasenko | 2015-05-08 12:26:02 [+0200]:
[snip]
With both gcc 4.7.2 and 4.9.2, sometimes gcc mysteriously doesn't inline
This patch fixes this for x86 atomic ops via s/inline/__always_inline/.
This decreases allyesconfig kernel by about 25k:
text data bss dec hex
* Andrew Morton | 2015-05-11 15:19:13 [-0700]:
Presumably Hagen didn't see the issue with spinlock functions. I
wonder why not.
I think it is a compiler version thing. Not sure why I didn't see it.
I suppose we should get both these consolidated into a coherent whole.
+1 (let wait for a
On 25 April 2015 at 12:31, Paul E. McKenney wrote:
> I am not arguing either way on the wisdom or lack thereof of gcc's
> inlining decisions. But PROVE_RCU=n and CONFIG_DEBUG_LOCK_ALLOC=n should
> make rcu_read_lock() and rcu_read_unlock() both be empty functions in
> a CONFIG_PREEMPT=n, which
On 25 April 2015 at 12:31, Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
I am not arguing either way on the wisdom or lack thereof of gcc's
inlining decisions. But PROVE_RCU=n and CONFIG_DEBUG_LOCK_ALLOC=n should
make rcu_read_lock() and rcu_read_unlock() both be empty functions in
a
* Paul E. McKenney | 2015-04-24 13:13:40 [-0700]:
>Hmmm... allyesconfig would have PROVE_RCU=y, which would mean that the
>above two would contain lockdep calls that might in some cases defeat
>inlining. With the more typical production choice of PROVE_RCU=n, I would
>expect these to just be a
On 24 April 2015 at 22:13, Paul E. McKenney wrote:
Hey Paul,
> Hmmm... allyesconfig would have PROVE_RCU=y, which would mean that the
> above two would contain lockdep calls that might in some cases defeat
> inlining. With the more typical production choice of PROVE_RCU=n, I would
> expect
On 24 April 2015 at 21:49, Andrew Morton wrote:
> I can't reproduce this with either gcc-4.8.2 or gcc-4.4.4. The patch
> makes zero difference to `size vmlinux' and a bit of poking around with
> nm doesn't show any out-of-lined versions of the functions you
> identify.
>
> So. More details,
* Paul E. McKenney | 2015-04-24 13:13:40 [-0700]:
Hmmm... allyesconfig would have PROVE_RCU=y, which would mean that the
above two would contain lockdep calls that might in some cases defeat
inlining. With the more typical production choice of PROVE_RCU=n, I would
expect these to just be a call
On 24 April 2015 at 22:13, Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Hey Paul,
Hmmm... allyesconfig would have PROVE_RCU=y, which would mean that the
above two would contain lockdep calls that might in some cases defeat
inlining. With the more typical production choice of
On 24 April 2015 at 21:49, Andrew Morton a...@linux-foundation.org wrote:
I can't reproduce this with either gcc-4.8.2 or gcc-4.4.4. The patch
makes zero difference to `size vmlinux' and a bit of poking around with
nm doesn't show any out-of-lined versions of the functions you
identify.
So.
patch - but this
should last for a while.
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: "David S. Miller"
Cc: "Paul E. McKenney"
Cc: x...@kernel.org
Link: http://lkml.kernel.org/r/1429565231-4609-1-git-send-email-ha...@jauu.net
Signed-off-by: Hagen Paul Pfeifer
---
net_generic()
-by: Hagen Paul Pfeifer ha...@jauu.net
---
net_generic() is a borderline candidate, probably to heavy for inlining.
Possible a candidate for removing static linkage and inline attributes?!
I don't touched the status yet - but I can change it too.
arch/x86/include/asm/bitops.h | 4 ++--
arch/x86
Commit-ID: 3462bd2adeadc49d9e126bca3b5536a3437a902d
Gitweb: http://git.kernel.org/tip/3462bd2adeadc49d9e126bca3b5536a3437a902d
Author: Hagen Paul Pfeifer
AuthorDate: Mon, 20 Apr 2015 23:27:11 +0200
Committer: Ingo Molnar
CommitDate: Wed, 22 Apr 2015 08:14:41 +0200
x86/asm: Always
On 22 April 2015 at 11:28, Ingo Molnar wrote:
> So I think the original patch makes sense (and I already applied it),
> we want known-simple and performance critical methods (such as atomic
> ops) always inlined.
Right. As I wrote I will post a follow up patch for the remaining
cases where
Commit-ID: 3462bd2adeadc49d9e126bca3b5536a3437a902d
Gitweb: http://git.kernel.org/tip/3462bd2adeadc49d9e126bca3b5536a3437a902d
Author: Hagen Paul Pfeifer ha...@jauu.net
AuthorDate: Mon, 20 Apr 2015 23:27:11 +0200
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 22 Apr 2015 08:14
On 22 April 2015 at 11:28, Ingo Molnar mi...@kernel.org wrote:
So I think the original patch makes sense (and I already applied it),
we want known-simple and performance critical methods (such as atomic
ops) always inlined.
Right. As I wrote I will post a follow up patch for the remaining
* Ingo Molnar | 2015-04-21 09:42:12 [+0200]:
Hey Ingo,
>So the thing is that allyesconfig turns on -Os:
>
> CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_CC_OPTIMIZE_FOR_SIZE seems to have no effect, The only option which
makes a difference is CONFIG_OPTIMIZE_INLINING! But this is not a big surprise:
On 21 April 2015 at 09:42, Ingo Molnar wrote:
Hey Ingo, Peter, Boris,
the environment is Debian with gcc version 4.9.2. I tried to reproduce
the results under Ubuntu 14.04 but their version (4.8.2!) seems fine:
at max one duplicate for each atomic_* function.
> So the thing is that
* Ingo Molnar | 2015-04-21 09:42:12 [+0200]:
Hey Ingo,
So the thing is that allyesconfig turns on -Os:
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_CC_OPTIMIZE_FOR_SIZE seems to have no effect, The only option which
makes a difference is CONFIG_OPTIMIZE_INLINING! But this is not a big surprise:
On 21 April 2015 at 09:42, Ingo Molnar mi...@kernel.org wrote:
Hey Ingo, Peter, Boris,
the environment is Debian with gcc version 4.9.2. I tried to reproduce
the results under Ubuntu 14.04 but their version (4.8.2!) seems fine:
at max one duplicate for each atomic_* function.
So the thing is
On 20 April 2015 at 23:56, Borislav Petkov wrote:
> Hmm, that must be config-specific as doing
>
> objdump -D vmlinux | grep -i "atomic_add"
>
> here gives me only "drm_atomic_add_affected_connectors" matches.
>
> It probably gets inlined here always...
Probably, the config is allyesconfig
. Peter Anvin
Cc: Peter Zijlstra
Signed-off-by: Hagen Paul Pfeifer
---
arch/x86/include/asm/atomic.h | 16
arch/x86/include/asm/atomic64_64.h | 8
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm
: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Peter Zijlstra pet...@infradead.org
Signed-off-by: Hagen Paul Pfeifer ha...@jauu.net
---
arch/x86/include/asm/atomic.h | 16
arch/x86/include/asm/atomic64_64.h | 8
On 20 April 2015 at 23:56, Borislav Petkov b...@alien8.de wrote:
Hmm, that must be config-specific as doing
objdump -D vmlinux | grep -i atomic_add
here gives me only drm_atomic_add_affected_connectors matches.
It probably gets inlined here always...
Probably, the config is allyesconfig
On 25 February 2015 at 00:16, Vikas Shivappa
wrote:
> +1.2 Why is CAT needed
> +-
> +
> +The CAT enables more cache resources to be made available for higher
> +priority applications based on guidance from the execution
> +environment.
> +
> +The architecture also allows
On 25 February 2015 at 00:16, Vikas Shivappa
vikas.shiva...@linux.intel.com wrote:
+1.2 Why is CAT needed
+-
+
+The CAT enables more cache resources to be made available for higher
+priority applications based on guidance from the execution
+environment.
+
+The
On 10 November 2014 13:50, Peter Zijlstra wrote:
> # env | grep XDG | wc -l
> 0
>
> Which renders it useless crap in my book.
>
> I agree on the .debug name being somewhat generic, also, it would be:
> man 8 file-hierarchy, but that too fails:
>
> $ man file-hierarchy
> No manual entry for
On 7 November 2014 09:21, Masami Hiramatsu
wrote:
> File Format
> ===
> All the cache files are placed under ~/.debug/ by default.
> The paths of buildid cache of binary/symbols are not changed.
>
> The SDT/probe caches are placed under the
> ~/.debug/.probes/path/to/bin/bu/ildid
> and
On 7 November 2014 09:21, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
File Format
===
All the cache files are placed under ~/.debug/ by default.
The paths of buildid cache of binary/symbols are not changed.
The SDT/probe caches are placed under the
On 10 November 2014 13:50, Peter Zijlstra pet...@infradead.org wrote:
# env | grep XDG | wc -l
0
Which renders it useless crap in my book.
I agree on the .debug name being somewhat generic, also, it would be:
man 8 file-hierarchy, but that too fails:
$ man file-hierarchy
No manual entry
On 25 September 2014 17:50, Michal Nazarewicz wrote:
> - * @min: minimum allowable value
> - * @max: maximum allowable value
> + * @lo: minimum allowable value
> + * @hi: maximum allowable value
Ok, but why do you rename min/max to low/high after so many years?
min/max is just perfect
Hagen
--
On 25 September 2014 17:50, Michal Nazarewicz min...@mina86.com wrote:
- * @min: minimum allowable value
- * @max: maximum allowable value
+ * @lo: minimum allowable value
+ * @hi: maximum allowable value
Ok, but why do you rename min/max to low/high after so many years?
min/max is just
On 20 August 2014 11:07, Alexander Holler wrote:
> For sure it could be better, but I'm already happy with the current
> imperfect solution which I can use now and not some perfect solution which
> might be available in some years.
Alexander, to make it clear: we cannot include mechanisms which
On 19 August 2014 21:36, Alexander Holler wrote:
> It doesn't have to work in every environment and it doesn't have to solve
> all existing problems in the world. ;)
>
> But it enables people to protect a bit more against malicious people or
> governments.
>
> And it is really very easy to use.
On 19 August 2014 21:36, Alexander Holler hol...@ahsoftware.de wrote:
It doesn't have to work in every environment and it doesn't have to solve
all existing problems in the world. ;)
But it enables people to protect a bit more against malicious people or
governments.
And it is really very
On 20 August 2014 11:07, Alexander Holler hol...@ahsoftware.de wrote:
For sure it could be better, but I'm already happy with the current
imperfect solution which I can use now and not some perfect solution which
might be available in some years.
Alexander, to make it clear: we cannot include
Wow, back in the days where I submitted the patch I saw improvement in
the generated code (focus on number of instructions). Don't know what
happends with gcc in the meantime. Anyway, patch and analysis looks
good. So from a clean-patch perspective you get an:
Signed-off-by: Hagen Paul Pfeifer
Wow, back in the days where I submitted the patch I saw improvement in
the generated code (focus on number of instructions). Don't know what
happends with gcc in the meantime. Anyway, patch and analysis looks
good. So from a clean-patch perspective you get an:
Signed-off-by: Hagen Paul Pfeifer ha
Hey Andi, Namhyung,
intention was just to raise hands, later there is probably no
possibility to change the command name without breaking scripts.
Anyway, the whole mechanism is awesome! ;-)
Hagen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hey Andi, Namhyung,
intention was just to raise hands, later there is probably no
possibility to change the command name without breaking scripts.
Anyway, the whole mechanism is awesome! ;-)
Hagen
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Probably too late, but IMHO the subcommand "download" is unhappy
named. What is "downloaded"? traces? Python helper libs for
perf-python support, I don't know it. What about "events-download",
"events-database", ...
I also thought about further sub-command to delete the cache, update
the cache,
Probably too late, but IMHO the subcommand download is unhappy
named. What is downloaded? traces? Python helper libs for
perf-python support, I don't know it. What about events-download,
events-database, ...
I also thought about further sub-command to delete the cache, update
the cache, limit
On 13 May 2014 00:51, Andi Kleen wrote:
> I implemented an automatic downloader to get the event file for the
> current CPU. The events are stored in ~/.events.
> Then perf adds a parser that converts the JSON format into perf event
> aliases, which then can be used directly as any other perf
On 13 May 2014 00:51, Andi Kleen a...@firstfloor.org wrote:
I implemented an automatic downloader to get the event file for the
current CPU. The events are stored in ~/.events.
Then perf adds a parser that converts the JSON format into perf event
aliases, which then can be used directly as
If all issues raised by Daniel are addresed:
Acked-by: Hagen Paul Pfeifer
But ...
>Future work:
>
>0. seccomp
>
>1. add extended BPF JIT for x86_64
>
>2. add inband old/new demux and extended BPF verifier, so that new programs
> can be loaded thro
If all issues raised by Daniel are addresed:
Acked-by: Hagen Paul Pfeifer ha...@jauu.net
But ...
Future work:
0. seccomp
1. add extended BPF JIT for x86_64
2. add inband old/new demux and extended BPF verifier, so that new programs
can be loaded through old sk_attach_filter
* Daniel Borkmann | 2014-03-01 01:30:00 [+0100]:
>>>as in 'struct bpf_insn' the immediate value is 32 bit, so for 64 bit
>>>comparisons, you'd still need to load to immediate values, right?
>>
>>there is no insn that use 64-bit immediate, since 64-bit immediates
>>are extremely rare. grep x86-64
* Daniel Borkmann | 2014-03-01 01:30:00 [+0100]:
as in 'struct bpf_insn' the immediate value is 32 bit, so for 64 bit
comparisons, you'd still need to load to immediate values, right?
there is no insn that use 64-bit immediate, since 64-bit immediates
are extremely rare. grep x86-64 asm code for
ize of the current CPU if they are
different for different models (e.g P4)? If this fails -> fall back to standard
size). But as I said - this is a idea.
See gcc/config/i386/driver-i386.c:host_detect_local_cpu() for more information
in the gcc devel branch.
Salaam
Hagen Paul Pfeifer
Increas
if they are
different for different models (e.g P4)? If this fails - fall back to standard
size). But as I said - this is a idea.
See gcc/config/i386/driver-i386.c:host_detect_local_cpu() for more information
in the gcc devel branch.
Salaam
Hagen Paul Pfeifer
Increase (double) the definition
at compile time and replace the static
#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
macros
My suggestion is added as an patch -- any superior suggestions
Shalom
Hagen Paul Pfeifer
Increase (double) the definition for INTERNODE_CACHE_SHIFT to accommodate a
higher cache line size f
and replace the static
#define L1_CACHE_BYTES (1 L1_CACHE_SHIFT)
macros
My suggestion is added as an patch -- any superior suggestions
Shalom
Hagen Paul Pfeifer
Increase (double) the definition for INTERNODE_CACHE_SHIFT to accommodate a
higher cache line size for l2 and l3 cacheline sizes
73 matches
Mail list logo
