On Thu 13-09-18 15:32:25, prakash.sangappa wrote:
>
>
> On 09/13/2018 01:40 AM, Michal Hocko wrote:
> > On Wed 12-09-18 13:23:58, Prakash Sangappa wrote:
> > > For analysis purpose it is useful to have numa node information
> > > corresponding mapped virtual address ranges of a process.
On Thu 13-09-18 15:32:25, prakash.sangappa wrote:
>
>
> On 09/13/2018 01:40 AM, Michal Hocko wrote:
> > On Wed 12-09-18 13:23:58, Prakash Sangappa wrote:
> > > For analysis purpose it is useful to have numa node information
> > > corresponding mapped virtual address ranges of a process.
Marcel Ziswiler writes:
> Hi Robert
>> arch/arm/boot/dts/Makefile| 2 +
>> arch/arm/boot/dts/mioa701.dts | 558
>
> Isn't that one supposed to be prefixed by pxa270-?
Good point, for v4.
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
...
>>
Marcel Ziswiler writes:
> Hi Robert
>> arch/arm/boot/dts/Makefile| 2 +
>> arch/arm/boot/dts/mioa701.dts | 558
>
> Isn't that one supposed to be prefixed by pxa270-?
Good point, for v4.
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
...
>>
Hi Chun-Yi,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc3 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Chun-Yi,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc3 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Thu, Sep 13, 2018 at 7:38 PM Martin Schwidefsky
wrote:
>
> I did push it to keys.gnupg.net, but the sub-key is brand new and
> probably takes some time to sync on the key server network.
That's probably it.
> The key is there on pgp.mit.edu this morning, it that to one you
> are using or do
On Thu, Sep 13, 2018 at 7:38 PM Martin Schwidefsky
wrote:
>
> I did push it to keys.gnupg.net, but the sub-key is brand new and
> probably takes some time to sync on the key server network.
That's probably it.
> The key is there on pgp.mit.edu this morning, it that to one you
> are using or do
On Fri, Sep 14, 2018 at 04:39:28AM +0800, kbuild test robot wrote:
> Hi Matti,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on regulator/for-next]
> [also build test ERROR on next-20180913]
> [cannot apply to v4.19-rc3]
> [
On Fri, Sep 14, 2018 at 04:39:28AM +0800, kbuild test robot wrote:
> Hi Matti,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on regulator/for-next]
> [also build test ERROR on next-20180913]
> [cannot apply to v4.19-rc3]
> [
On Thu, 13 Sep 2018 16:26:38 -1000
Linus Torvalds wrote:
> On Thu, Sep 13, 2018 at 2:02 AM Martin Schwidefsky
> wrote:
> >
> > this is the first try to do a pull request for s390 with a signed tag.
> > I keep my fingers crossed that the setup works as intended.
> >
> > I have used the 8A8FDAE0
On Thu, 13 Sep 2018 16:26:38 -1000
Linus Torvalds wrote:
> On Thu, Sep 13, 2018 at 2:02 AM Martin Schwidefsky
> wrote:
> >
> > this is the first try to do a pull request for s390 with a signed tag.
> > I keep my fingers crossed that the setup works as intended.
> >
> > I have used the 8A8FDAE0
Clang warns when an implicit conversion is done between enumerated
types:
drivers/block/drbd/drbd_state.c:708:8: warning: implicit conversion from
enumeration type 'enum drbd_ret_code' to different enumeration type
'enum drbd_state_rv' [-Wenum-conversion]
rv = ERR_INTR;
Clang warns when an implicit conversion is done between enumerated
types:
drivers/block/drbd/drbd_state.c:708:8: warning: implicit conversion from
enumeration type 'enum drbd_ret_code' to different enumeration type
'enum drbd_state_rv' [-Wenum-conversion]
rv = ERR_INTR;
On Thu, Sep 13, 2018 at 04:52:09PM +0100, David Howells wrote:
> Add two new iterator types to iov_iter:
>
> (1) ITER_MAPPING
>
> This walks through a set of pages attached to an address_space that
> are pinned or locked, starting at a given page and offset and walking
> for the
On Thu, Sep 13, 2018 at 04:52:09PM +0100, David Howells wrote:
> Add two new iterator types to iov_iter:
>
> (1) ITER_MAPPING
>
> This walks through a set of pages attached to an address_space that
> are pinned or locked, starting at a given page and offset and walking
> for the
syzbot has found a reproducer for the following crash on:
HEAD commit:f8dcd0279214 Add linux-next specific files for 20180913
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=157a332140
kernel config: https://syzkaller.appspot.com/x/.config?x
syzbot has found a reproducer for the following crash on:
HEAD commit:f8dcd0279214 Add linux-next specific files for 20180913
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=157a332140
kernel config: https://syzkaller.appspot.com/x/.config?x
On 09/13/2018 09:35 AM, Cédric Le Goater wrote:
On 09/13/2018 05:57 PM, Guenter Roeck wrote:
On Thu, Sep 13, 2018 at 05:48:59PM +0200, Cédric Le Goater wrote:
On 09/13/2018 03:33 PM, Guenter Roeck wrote:
[ ... ]
/*
* The state machine needs some refinement. It is only used to track
On 09/13/2018 09:35 AM, Cédric Le Goater wrote:
On 09/13/2018 05:57 PM, Guenter Roeck wrote:
On Thu, Sep 13, 2018 at 05:48:59PM +0200, Cédric Le Goater wrote:
On 09/13/2018 03:33 PM, Guenter Roeck wrote:
[ ... ]
/*
* The state machine needs some refinement. It is only used to track
syzbot has found a reproducer for the following crash on:
HEAD commit:f8dcd0279214 Add linux-next specific files for 20180913
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14828b2140
kernel config: https://syzkaller.appspot.com/x/.config?x
syzbot has found a reproducer for the following crash on:
HEAD commit:f8dcd0279214 Add linux-next specific files for 20180913
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14828b2140
kernel config: https://syzkaller.appspot.com/x/.config?x
Commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events
properly") moved interrupt acknowledgment to the end of the interrupt
handler. In part this was done because the AST2500 datasheet says:
I2CD10 Interrupt Status Register
bit 2 Receive Done Interrupt status
S/W
Commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events
properly") moved interrupt acknowledgment to the end of the interrupt
handler. In part this was done because the AST2500 datasheet says:
I2CD10 Interrupt Status Register
bit 2 Receive Done Interrupt status
S/W
Hi,
On 10/09/18 07:43, Vincent Guittot wrote:
> When CPUs have different capacity because of RT/DL tasks or
> micro-architecture or max frequency differences, there are situation where
> the imbalance is not correctly set to migrate waiting task on the idle CPU.
>
> The UC uses the force_balance
Hi,
On 10/09/18 07:43, Vincent Guittot wrote:
> When CPUs have different capacity because of RT/DL tasks or
> micro-architecture or max frequency differences, there are situation where
> the imbalance is not correctly set to migrate waiting task on the idle CPU.
>
> The UC uses the force_balance
From: Andi Kleen
I often forget all the options that --itrace accepts. Instead of burying
them in the man page only report them in the normal command line help
too to make them easier accessible.
v2: Align
Signed-off-by: Andi Kleen
---
tools/perf/builtin-inject.c | 3 ++-
From: Andi Kleen
Add short cut options to print PT call trace and call-ret-trace,
for calls and call and returns. Roughly corresponds to ftrace
function tracer and function graph tracer.
Just makes these common use cases nicer to use.
% perf record -a -e intel_pt// sleep 1
% perf script
From: Andi Kleen
By default perf script for itrace outputs sampled instructions or
branches. In my experience this is confusing to users because it's
hard to correlate with real program behavior. The sampling makes
sense for tools like report that actually sample to reduce
the run time, but run
From: Andi Kleen
Currently sym and dso require printing ip and addr because
the print function is tied to those outputs. With callindent
it makes sense to print the symbol or dso without numerical
IP or ADDR. So change the dependency check to only check the
underlying attribute.
Also the branch
Implement a range of improvements to make it easier to look
at itrace traces with perf script. Nothing here couldn't be done
before with some additional scripting, but add simple high
level options to make it easier to use.
% perf record -e intel_pt//k -a sleep 1
Show function calls:
% perf
From: Andi Kleen
Add a --insn-trace short hand option for decoding and disassembling
instruction streams for intel_pt. This automatically pipes the
output into the xed disassembler to generate disassembled instructions.
This just makes this use model much nicer to use
Before
% perf record -e
From: Andi Kleen
I often forget all the options that --itrace accepts. Instead of burying
them in the man page only report them in the normal command line help
too to make them easier accessible.
v2: Align
Signed-off-by: Andi Kleen
---
tools/perf/builtin-inject.c | 3 ++-
From: Andi Kleen
Add short cut options to print PT call trace and call-ret-trace,
for calls and call and returns. Roughly corresponds to ftrace
function tracer and function graph tracer.
Just makes these common use cases nicer to use.
% perf record -a -e intel_pt// sleep 1
% perf script
From: Andi Kleen
By default perf script for itrace outputs sampled instructions or
branches. In my experience this is confusing to users because it's
hard to correlate with real program behavior. The sampling makes
sense for tools like report that actually sample to reduce
the run time, but run
From: Andi Kleen
Currently sym and dso require printing ip and addr because
the print function is tied to those outputs. With callindent
it makes sense to print the symbol or dso without numerical
IP or ADDR. So change the dependency check to only check the
underlying attribute.
Also the branch
Implement a range of improvements to make it easier to look
at itrace traces with perf script. Nothing here couldn't be done
before with some additional scripting, but add simple high
level options to make it easier to use.
% perf record -e intel_pt//k -a sleep 1
Show function calls:
% perf
From: Andi Kleen
Add a --insn-trace short hand option for decoding and disassembling
instruction streams for intel_pt. This automatically pipes the
output into the xed disassembler to generate disassembled instructions.
This just makes this use model much nicer to use
Before
% perf record -e
From: Andi Kleen
Add an interface to the auto pager code that allows callers
to overwrite the pager.
Signed-off-by: Andi Kleen
---
tools/lib/subcmd/pager.c | 11 ++-
tools/lib/subcmd/pager.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git
From: Andi Kleen
Now that we don't need to print the IP/ADDR for callindent the DSO
is also not printed. It's useful for some cases, so add an own DSO
printout for callindent for the case when IP/ADDR is not enabled.
Before:
% perf script --itrace=cr -F +callindent,-ip,-sym,-symoff,-addr
From: Andi Kleen
Add a ftrace style --graph-function argument to perf script that allows
to print itrace function calls only below a given function. This
makes it easier to find the code of interest in a large trace.
% perf record -e intel_pt//k -a sleep 1
% perf script --graph-function
From: Andi Kleen
Add an interface to the auto pager code that allows callers
to overwrite the pager.
Signed-off-by: Andi Kleen
---
tools/lib/subcmd/pager.c | 11 ++-
tools/lib/subcmd/pager.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git
From: Andi Kleen
Now that we don't need to print the IP/ADDR for callindent the DSO
is also not printed. It's useful for some cases, so add an own DSO
printout for callindent for the case when IP/ADDR is not enabled.
Before:
% perf script --itrace=cr -F +callindent,-ip,-sym,-symoff,-addr
From: Andi Kleen
Add a ftrace style --graph-function argument to perf script that allows
to print itrace function calls only below a given function. This
makes it easier to find the code of interest in a large trace.
% perf record -e intel_pt//k -a sleep 1
% perf script --graph-function
On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because
the ocotp clock needs to be enabled first. Add support for reading
OCOTP through the nvmem API instead.
Signed-off-by: Anson Huang
---
drivers/cpufreq/imx6q-cpufreq.c | 39 +++
1 file changed, 19
On i.MX6UL, accessing OCOTP directly is wrong because the ocotp clock
needs to be enabled first, so use the nvmem-cells binding instead.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi
On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because
the ocotp clock needs to be enabled first. Add support for reading
OCOTP through the nvmem API instead.
Signed-off-by: Anson Huang
---
drivers/cpufreq/imx6q-cpufreq.c | 39 +++
1 file changed, 19
On i.MX6UL, accessing OCOTP directly is wrong because the ocotp clock
needs to be enabled first, so use the nvmem-cells binding instead.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi
CON_PRINTBUFFER console registration requires us to do several
preparation steps:
- Rollback console_seq to replay logbuf messages which were already
seen on other consoles;
- Set exclusive_console flag so console_unlock() will ->write() logbuf
messages only to the exclusive_console driver.
CON_PRINTBUFFER console registration requires us to do several
preparation steps:
- Rollback console_seq to replay logbuf messages which were already
seen on other consoles;
- Set exclusive_console flag so console_unlock() will ->write() logbuf
messages only to the exclusive_console driver.
On Thu, Sep 13, 2018 at 10:15 PM Rafael J. Wysocki wrote:
>
> On Thursday, September 13, 2018 12:03:36 PM CEST James Wang wrote:
> > This is a multi-part message in MIME format.
> > --F5519E624D0AD1E3F7DDA019
> > Content-Type: text/plain; charset=utf-8
> > Content-Transfer-Encoding:
On Thu, Sep 13, 2018 at 10:15 PM Rafael J. Wysocki wrote:
>
> On Thursday, September 13, 2018 12:03:36 PM CEST James Wang wrote:
> > This is a multi-part message in MIME format.
> > --F5519E624D0AD1E3F7DDA019
> > Content-Type: text/plain; charset=utf-8
> > Content-Transfer-Encoding:
On Thu, Sep 13, 2018 at 07:10:35PM +0300, Alexey Budankov wrote:
> Hi,
Hello,
>
> On 13.09.2018 15:54, Jiri Olsa wrote:
> > hi,
> > sending *RFC* for threads support in perf record command.
> >
> > In big picture this patchset adds perf record --threads
> > option that allows to create threads
On Thu, Sep 13, 2018 at 07:10:35PM +0300, Alexey Budankov wrote:
> Hi,
Hello,
>
> On 13.09.2018 15:54, Jiri Olsa wrote:
> > hi,
> > sending *RFC* for threads support in perf record command.
> >
> > In big picture this patchset adds perf record --threads
> > option that allows to create threads
On Thu, Sep 13, 2018 at 10:56:48PM +0200, Arnd Bergmann wrote:
> Yes, I saw that too, but couldn't figure out exactly what ipwireless
> does. I suppose it is some serial port driver that comes with a
> hardcoded ppp implementation instead of a switchable ldisc?
NFI...
> > > * SIOCGIFNAME,
On Thu, Sep 13, 2018 at 10:56:48PM +0200, Arnd Bergmann wrote:
> Yes, I saw that too, but couldn't figure out exactly what ipwireless
> does. I suppose it is some serial port driver that comes with a
> hardcoded ppp implementation instead of a switchable ldisc?
NFI...
> > > * SIOCGIFNAME,
On Thu, Sep 13, 2018 at 2:02 AM Martin Schwidefsky
wrote:
>
> this is the first try to do a pull request for s390 with a signed tag.
> I keep my fingers crossed that the setup works as intended.
>
> I have used the 8A8FDAE0 signing sub-key of my 26AE5DD2 master key:
The signed tag looks ok, but
On Thu, Sep 13, 2018 at 2:02 AM Martin Schwidefsky
wrote:
>
> this is the first try to do a pull request for s390 with a signed tag.
> I keep my fingers crossed that the setup works as intended.
>
> I have used the 8A8FDAE0 signing sub-key of my 26AE5DD2 master key:
The signed tag looks ok, but
On (09/13/18 21:22), Steven Rostedt wrote:
> > Good call. It was a fast path for pr_cont("\n").
> > But it made me wondering and I did some grepping
> >
>
> [..]
>
> > kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
>
> Note, looking at the history of that, I was just
On (09/13/18 21:22), Steven Rostedt wrote:
> > Good call. It was a fast path for pr_cont("\n").
> > But it made me wondering and I did some grepping
> >
>
> [..]
>
> > kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
>
> Note, looking at the history of that, I was just
On 9/13/18 6:24 PM, Thomas Gleixner wrote:
> On Thu, 13 Sep 2018, Brijesh Singh wrote:
>>
>> +void __weak mem_encrypt_free_decrypted_mem(void) { }
>> +
>> void __ref free_initmem(void)
>> {
>> e820__reallocate_tables();
>>
>> +mem_encrypt_free_decrypted_mem();
>> +
>>
On 9/13/18 6:24 PM, Thomas Gleixner wrote:
> On Thu, 13 Sep 2018, Brijesh Singh wrote:
>>
>> +void __weak mem_encrypt_free_decrypted_mem(void) { }
>> +
>> void __ref free_initmem(void)
>> {
>> e820__reallocate_tables();
>>
>> +mem_encrypt_free_decrypted_mem();
>> +
>>
On (09/13/18 21:12), Steven Rostedt wrote:
> >
> > +#define __SEQ_BUF_INITIALIZER(buf, length) {
> > \
> > + .buffer = (buf),\
> > + .size = (length), \
> > + .len
On (09/13/18 21:12), Steven Rostedt wrote:
> >
> > +#define __SEQ_BUF_INITIALIZER(buf, length) {
> > \
> > + .buffer = (buf),\
> > + .size = (length), \
> > + .len
On Thu, Sep 13, 2018 at 02:43:35PM -0700, Matt Ranostay wrote:
> On Wed, Sep 12, 2018 at 8:51 PM Song Qiang wrote:
> >
> > This driver tries to access a block of data on a i2c bus and it tries
> > to manually make a device command frame and a consecutively read frame,
> > then uses i2c_transfer()
On Thu, Sep 13, 2018 at 02:43:35PM -0700, Matt Ranostay wrote:
> On Wed, Sep 12, 2018 at 8:51 PM Song Qiang wrote:
> >
> > This driver tries to access a block of data on a i2c bus and it tries
> > to manually make a device command frame and a consecutively read frame,
> > then uses i2c_transfer()
$2Million Donation To You. Please Contact (donation_foundatio...@inbox.ru) For
Claim.
Thanks
This email, including any attachments, is confidential and contains proprietary
content and may be legally privileged. This transmission is intended only for
the designated recipient(s), and any
$2Million Donation To You. Please Contact (donation_foundatio...@inbox.ru) For
Claim.
Thanks
This email, including any attachments, is confidential and contains proprietary
content and may be legally privileged. This transmission is intended only for
the designated recipient(s), and any
On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
wrote:
> On 05/09/2018 04:31 PM, Dave Hansen wrote:
> > On 05/07/2018 06:16 PM, prakash.sangappa wrote:
> >> It will be /proc//numa_vamaps. Yes, the behavior will be
> >> different with respect to seeking. Output will still be text and
> >> the
On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
wrote:
> On 05/09/2018 04:31 PM, Dave Hansen wrote:
> > On 05/07/2018 06:16 PM, prakash.sangappa wrote:
> >> It will be /proc//numa_vamaps. Yes, the behavior will be
> >> different with respect to seeking. Output will still be text and
> >> the
Remove duplicated include.
Signed-off-by: YueHaibing
---
sound/soc/qcom/qdsp6/q6asm-dai.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/qcom/qdsp6/q6asm-dai.c b/sound/soc/qcom/qdsp6/q6asm-dai.c
index c75fab3..c3806d7 100644
--- a/sound/soc/qcom/qdsp6/q6asm-dai.c
+++
Remove duplicated include.
Signed-off-by: YueHaibing
---
sound/soc/qcom/qdsp6/q6asm-dai.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/qcom/qdsp6/q6asm-dai.c b/sound/soc/qcom/qdsp6/q6asm-dai.c
index c75fab3..c3806d7 100644
--- a/sound/soc/qcom/qdsp6/q6asm-dai.c
+++
On Thu, 13 Sep 2018 23:28:02 +0900
Sergey Senozhatsky wrote:
> Good call. It was a fast path for pr_cont("\n").
> But it made me wondering and I did some grepping
>
[..]
> kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
Note, looking at the history of that, I was
On Thu, 13 Sep 2018 23:28:02 +0900
Sergey Senozhatsky wrote:
> Good call. It was a fast path for pr_cont("\n").
> But it made me wondering and I did some grepping
>
[..]
> kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
Note, looking at the history of that, I was
On Thu, 13 Sep 2018 16:12:54 +0900
Sergey Senozhatsky wrote:
Signed-off-by: Sergey Senozhatsky
> ---
> include/linux/seq_buf.h | 35 +++
> lib/seq_buf.c | 46 +
> 2 files changed, 81 insertions(+)
>
> diff --git
On Thu, 13 Sep 2018 16:12:54 +0900
Sergey Senozhatsky wrote:
Signed-off-by: Sergey Senozhatsky
> ---
> include/linux/seq_buf.h | 35 +++
> lib/seq_buf.c | 46 +
> 2 files changed, 81 insertions(+)
>
> diff --git
On Thu, Sep 13, 2018 at 10:23:28AM -0400, Jerome Glisse wrote:
> On Thu, Sep 13, 2018 at 03:37:22PM +0800, Peter Xu wrote:
> > On Wed, Sep 12, 2018 at 09:24:39AM -0400, Jerome Glisse wrote:
> > > On Wed, Sep 12, 2018 at 09:03:55AM -0400, Jerome Glisse wrote:
> > > > On Wed, Sep 12, 2018 at
On Thu, Sep 13, 2018 at 10:23:28AM -0400, Jerome Glisse wrote:
> On Thu, Sep 13, 2018 at 03:37:22PM +0800, Peter Xu wrote:
> > On Wed, Sep 12, 2018 at 09:24:39AM -0400, Jerome Glisse wrote:
> > > On Wed, Sep 12, 2018 at 09:03:55AM -0400, Jerome Glisse wrote:
> > > > On Wed, Sep 12, 2018 at
Hi Brijesh,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tip/x86/core]
[also build test WARNING on v4.19-rc3 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Brijesh,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tip/x86/core]
[also build test WARNING on v4.19-rc3 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On 09/13/2018 05:10 PM, Andrew Morton wrote:
>> Also, VMAs having THP pages can have a mix of 4k pages and hugepages.
>> The page walks would be efficient in scanning and determining if it is
>> a THP huge page and step over it. Whereas using the API, the application
>> would not know what page
On 09/13/2018 05:10 PM, Andrew Morton wrote:
>> Also, VMAs having THP pages can have a mix of 4k pages and hugepages.
>> The page walks would be efficient in scanning and determining if it is
>> a THP huge page and step over it. Whereas using the API, the application
>> would not know what page
On Thu, 13 Sep 2018 15:32:25 -0700 "prakash.sangappa"
wrote:
> >> https://marc.info/?t=15252407341=1=2
> > It would be really great to give a short summary of the previous
> > discussion. E.g. why do we need a proc interface in the first place when
> > we already have an API to query for
On Thu, 13 Sep 2018 15:32:25 -0700 "prakash.sangappa"
wrote:
> >> https://marc.info/?t=15252407341=1=2
> > It would be really great to give a short summary of the previous
> > discussion. E.g. why do we need a proc interface in the first place when
> > we already have an API to query for
Hey Peter,
On Thu, Sep 06, 2018 at 09:21:49AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 05, 2018 at 02:47:07PM -0700, Andi Kleen wrote:
> > On Wed, Sep 05, 2018 at 08:53:17AM -0700, Eduardo Valentin wrote:
> > > On Wed, Sep 05, 2018 at 10:52:12AM +0200, Peter Zijlstra wrote:
> > > > On Thu, Aug
Hey Peter,
On Thu, Sep 06, 2018 at 09:21:49AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 05, 2018 at 02:47:07PM -0700, Andi Kleen wrote:
> > On Wed, Sep 05, 2018 at 08:53:17AM -0700, Eduardo Valentin wrote:
> > > On Wed, Sep 05, 2018 at 10:52:12AM +0200, Peter Zijlstra wrote:
> > > > On Thu, Aug
The naked attribute is supported by at least gcc >= 4.6 (for ARM,
which is the only current user), gcc >= 8 (for x86), clang >= 3.1
and icc >= 13. See https://godbolt.org/z/350Dyc
Therefore, move it out of compiler-gcc.h so that the definition
is shared by all compilers.
This also fixes Clang
Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone
and noinline on __naked functions") added noinline and noclone
as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0.
Since now the minimum gcc supported version is 4.6,
we can clean it up.
See
The naked attribute is supported by at least gcc >= 4.6 (for ARM,
which is the only current user), gcc >= 8 (for x86), clang >= 3.1
and icc >= 13. See https://godbolt.org/z/350Dyc
Therefore, move it out of compiler-gcc.h so that the definition
is shared by all compilers.
This also fixes Clang
Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone
and noinline on __naked functions") added noinline and noclone
as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0.
Since now the minimum gcc supported version is 4.6,
we can clean it up.
See
These two patches are the 5th and 6th of the Compiler Attributes series,
which Stefan and Nick requested to go into v4.19 so that the clang ARM32
build is fixed. The v5 of Compiler Attributes will have these two removed
if this goes in.
Miguel Ojeda (2):
Compiler Attributes: naked was fixed in
These two patches are the 5th and 6th of the Compiler Attributes series,
which Stefan and Nick requested to go into v4.19 so that the clang ARM32
build is fixed. The v5 of Compiler Attributes will have these two removed
if this goes in.
Miguel Ojeda (2):
Compiler Attributes: naked was fixed in
Linus,
Please pull the following changes for Hexagon; they contain some fixes for
compile
warnings.
Thanks,
Richard Kuo
The following changes since commit 11da3a7f84f19c26da6f86af878298694ede0804:
Linux 4.19-rc3 (2018-09-09 17:26:43 -0700)
are available in the git repository at:
Linus,
Please pull the following changes for Hexagon; they contain some fixes for
compile
warnings.
Thanks,
Richard Kuo
The following changes since commit 11da3a7f84f19c26da6f86af878298694ede0804:
Linux 4.19-rc3 (2018-09-09 17:26:43 -0700)
are available in the git repository at:
On Fri, Sep 14, 2018 at 12:27:49AM +0100, David Howells wrote:
> Al Viro wrote:
>
> > It's too early for AFD postings. And you *are* tempting
> > me to throw into the tree as many anti-C++ devices as can be
> > done tastefully, just to stop somebody attempting that insanity
> > in the
On Fri, Sep 14, 2018 at 12:27:49AM +0100, David Howells wrote:
> Al Viro wrote:
>
> > It's too early for AFD postings. And you *are* tempting
> > me to throw into the tree as many anti-C++ devices as can be
> > done tastefully, just to stop somebody attempting that insanity
> > in the
On Thu, 13 Sep 2018, Brijesh Singh wrote:
>
> +static void __init kvmclock_init_mem(void)
> +{
> + unsigned int ncpus = num_possible_cpus() - HVC_BOOT_ARRAY_SIZE;
> + unsigned int order = get_order(ncpus * sizeof(*hvclock_mem));
> + struct page *p;
> + int r;
> +
> + p =
On Thu, 13 Sep 2018, Brijesh Singh wrote:
>
> +static void __init kvmclock_init_mem(void)
> +{
> + unsigned int ncpus = num_possible_cpus() - HVC_BOOT_ARRAY_SIZE;
> + unsigned int order = get_order(ncpus * sizeof(*hvclock_mem));
> + struct page *p;
> + int r;
> +
> + p =
Al Viro wrote:
> It's too early for AFD postings. And you *are* tempting
> me to throw into the tree as many anti-C++ devices as can be
> done tastefully, just to stop somebody attempting that insanity
> in the earnest.
You would deliberately break the UAPI header files to make sure that
Al Viro wrote:
> It's too early for AFD postings. And you *are* tempting
> me to throw into the tree as many anti-C++ devices as can be
> done tastefully, just to stop somebody attempting that insanity
> in the earnest.
You would deliberately break the UAPI header files to make sure that
1 - 100 of 1846 matches
Mail list logo
