The document, at Documentation/admin-guide/pstore-block.rst,
tells user how to use pstore_blk and the attentions about panic
read/write
Signed-off-by: liaoweixiong
---
Documentation/admin-guide/pstore-block.rst | 233 +
MAINTAINERS| 1
blkoops is a sample for pstore/blk. It can only record oops, excluding
panics as no read/write apis for panic registered. It support settings
on Kconfg/device tree/module parameters. It can record oops log even
power failure if "PSTORE_BLKOOPS_BLKDEV" on Kconfig or "block-device"
on dts or "blkdev"
Create DT binding document for blkoops.
Signed-off-by: liaoweixiong
---
.../devicetree/bindings/pstore/blkoops.txt | 53 ++
MAINTAINERS| 1 +
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindin
pstore_blk is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_blk?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fact, there is already a sample
To enable pmsg, just set pmsg_size when block device register blkzone.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 21
fs/pstore/blkoops.c| 11 ++
fs/pstore/blkzone.c| 254 +
include/linux/pstore_blk.h | 1 +
4
Why should we need pstore_block?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have b
On Tue, Feb 19, 2019 at 01:42:13PM +0900, Masahiro Yamada wrote:
> On Tue, Feb 19, 2019 at 1:14 PM Masahiro Yamada
> wrote:
> >
> > On Fri, Feb 15, 2019 at 11:48 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
> > > > Introduce
...and use a commit with an obnoxiously long summary in the example to
make it abundantly clear that keeping the tag on a single line takes
priority over wrapping at 75 columns. Without the explicit exemption,
one might assume splitting the tag is acceptable, even encouraged, e.g.
due to being con
On 2/18/2019 10:40 PM, Len Brown wrote:
From: Len Brown
Some new systems have multiple software-visible die within each package.
The new CPUID.1F leaf can enumerate this multi-die/package topology.
CPUID.1F a super-set of the CPUID.B "Extended Toplogy Leaf",
and a common updated routine can
On 2/18/2019 10:40 PM, Len Brown wrote:
From: Len Brown
like core_siblings, except it shows which die are in the same package.
This is needed for lscpu(1) to correctly display die topology.
Signed-off-by: Len Brown
Cc: linux-doc@vger.kernel.org
Signed-off-by: Len Brown
---
Documentatio
On 12/02/2019 18:02, Catalin Marinas wrote:
> On Mon, Feb 11, 2019 at 12:32:55PM -0800, Evgenii Stepanov wrote:
>> On Mon, Feb 11, 2019 at 9:28 AM Kevin Brodsky wrote:
>>> On 19/12/2018 12:52, Dave Martin wrote:
Really, the kernel should do the expected thing with all "non-weird"
memory.
Thanks for the comments, Kan,
>> diff --git a/Documentation/cputopology.txt
>> b/Documentation/cputopology.txt index 287213b4517b..7dd2ae3df233
>> 100644
>> --- a/Documentation/cputopology.txt
>> +++ b/Documentation/cputopology.txt
>> @@ -56,6 +56,16 @@ core_siblings_list:
>> human-readable
>> @@ -461,7 +463,7 @@ static bool match_llc(struct cpuinfo_x86 *c, struct
>> cpuinfo_x86 *o)
>>*/
>> static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
>> {
>> -if (c->>phys_proc_id == o->>phys_proc_id)
>> +if (c->>cpu_die_id == o->>cpu_die_id)
>> ret
On 2/18/19 7:22 PM, Len Brown wrote:
> No semantic changes.
>
> Signed-off-by: Len Brown
> Cc: linux-doc@vger.kernel.org
> Signed-off-by: Len Brown
> ---
> Documentation/cputopology.txt | 34 +-
> 1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git
On 2/19/2019 1:43 PM, Brown, Len wrote:
Thanks for the comments, Kan,
diff --git a/Documentation/cputopology.txt
b/Documentation/cputopology.txt index 287213b4517b..7dd2ae3df233
100644
--- a/Documentation/cputopology.txt
+++ b/Documentation/cputopology.txt
@@ -56,6 +56,16 @@ core_siblings_li
>> +if CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are selected, respectively.
>>
>> CONFIG_SCHED_BOOK and CONFIG_DRAWER are currently only used on s390,
>> where
>fwiw:CONFIG_SCHED_DRAWER
Heh. Seems that every line of update to a .txt files uncovers two lines of
existing
Describe cgroup v2 freezer interface in the cgroup v2 admin guide.
Signed-off-by: Roman Gushchin
Reviewed-by: Mike Rapoport
Cc: Tejun Heo
Cc: linux-doc@vger.kernel.org
Cc: kernel-t...@fb.com
---
Documentation/admin-guide/cgroup-v2.rst | 27 +
1 file changed, 27 insertio
On 2019/2/19 11:40, Len Brown wrote:
From: Len Brown
Some new systems have multiple software-visible die within each package.
The new CPUID.1F leaf can enumerate this multi-die/package topology.
CPUID.1F a super-set of the CPUID.B "Extended Toplogy Leaf",
and a common updated routine can parse
On Tue, Feb 19, 2019 at 9:59 PM Like Xu wrote:
> > -/* leaf 0xb sub-leaf types */
> > +/* extended topology sub-leaf types */
> > #define INVALID_TYPE0
> > #define SMT_TYPE1
> > #define CORE_TYPE 2
> > +#define DIE_TYPE 5
>
> This patch set is going to export die topology
19 matches
Mail list logo
