When an event is disabled the "tracking" events
selected by the 'mmap', 'comm' and 'task' bits of
struct perf_event_attr, are also disabled. However,
the information those events provide is necessary to
resolve symbols for when the main event is re-enabled.
The "tracking" events can be kept
Hi
This is an alternative to the 'keep tracking' flag patch
which is here:
http://marc.info/?l=linux-kernel=137242545521246=2
perf tools is updated and a test added to demonstrate the
new event.
Adrian Hunter (3):
perf: add a dummy software event to keep tracking
perf
Hello,
On Wed, Aug 07, 2013 at 01:28:25PM +0200, Michal Hocko wrote:
> There is no limit for the maximum number of threshold events registered
> per memcg. This might lead to an user triggered memory depletion if a
> regular user is allowed to register on memory.[memsw.]usage_in_bytes
> eventfd
Greetings
You are a beneficiary to my late clients Will and Testament, late James
Jampbell made his inheritance in your favour. i need your attention on this
issue.
Barr Colin Lee.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 08/07/2013 09:09 PM, Takuya Yoshikawa wrote:
> On Tue, 30 Jul 2013 21:02:08 +0800
> Xiao Guangrong wrote:
>
>> @@ -2342,6 +2358,13 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>> */
>> kvm_flush_remote_tlbs(kvm);
>>
>> +if (kvm->arch.rcu_free_shadow_page) {
>> +
On Wed, Aug 07, 2013 at 09:08:36AM -0400, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of oom_control events
> > registered per memcg. This might lead to an user triggered memory
> > depletion if a
On Tue, 30 Jul 2013 21:02:08 +0800
Xiao Guangrong wrote:
> @@ -2342,6 +2358,13 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>*/
> kvm_flush_remote_tlbs(kvm);
>
> + if (kvm->arch.rcu_free_shadow_page) {
> + sp = list_first_entry(invalid_list, struct
On Tue, 06 Aug, at 08:45:08PM, Roy Franz wrote:
> The x86/AMD64 EFI stubs must us a call wrapper to convert between
> the Linux and EFI ABIs, so void pointers are sufficient. For ARM,
> the ABIs are compatible, so we can directly invoke the function
> pointers. The functions that are used by the
On Tue, 06 Aug, at 08:45:06PM, Roy Franz wrote:
> Rename variables to be not initrd specific, as now the function
> loads arbitrary files.
>
> Signed-off-by: Roy Franz
> ---
> drivers/firmware/efi/efi-stub-helper.c | 92
>
> 1 file changed, 46 insertions(+),
**_usb_get_phy_**() APIs should generate equivalent
error codes in case of failure in getting phy. There's no
need of returning NULL pointer, like in devm_usb_get_phy()
or devm_usb_get_phy_dev(), since it's nowhere handled.
Earlier series of patches starting:
9ee1c7f usb: host: ohci-exynos: fix
On Tue, 06 Aug, at 08:44:59PM, Roy Franz wrote:
> Signed-off-by: Roy Franz
> ---
> arch/x86/boot/compressed/eboot.c | 38 +++--
> drivers/firmware/efi/efi-stub-helper.c | 96
> +---
> 2 files changed, 72 insertions(+), 62 deletions(-)
For future
On Tue, 06 Aug, at 08:45:00PM, Roy Franz wrote:
> Rename them to be more similar, as low_free() could be used to free
> memory allocated by both high_alloc() and low_alloc().
> high_alloc() -> efi_high_alloc()
> low_alloc() -> efi_low_alloc()
> low_free() -> efi_free()
>
> Signed-off-by: Roy
Hello, Michal.
On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> There is no limit for the maximum number of oom_control events
> registered per memcg. This might lead to an user triggered memory
> depletion if a regular user is allowed to register events.
>
> Let's be more strict
netlink_send is supposed to send just the cn_msg+hv_kvp_msg via netlink.
Currently it sets an incorrect iovec size, as reported by valgrind.
In the case of registering with the kernel the allocated buffer is large
enough to hold nlmsghdr+cn_msg+hv_kvp_msg, no overrun happens. In the
case of
On Tue, Aug 06, 2013 at 02:08:15PM +0100, Mark Rutland wrote:
> On Tue, Aug 06, 2013 at 12:59:21PM +0100, Will Deacon wrote:
> > But we already check `event->pmu != leader_pmu' in validate_event, so we
> > shouldn't get anywhere nearer calling get_event_idx in the case you
> > describe. It sounds
On Tue, Aug 06, 2013 at 11:34:35PM +0200, Mathias Krause wrote:
> Commit a5463cd3 "ARM: make vectors page inaccessible from userspace"
> introduced a typo making arch_vma_name() always return "[vectors]".
> Fix up that regression (of the hush-hush security fix).
And if you search the list
On Wed, Aug 07, 2013 at 06:24:56PM +0800, Lai Jiangshan wrote:
> Although all articles declare that rcu read site is deadlock-immunity.
> It is not true for rcu-preempt, it will be deadlock if rcu read site
> overlaps with scheduler lock.
The real rule is that if the scheduler does its outermost
Hi,
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
@@ -0,0 +1,19 @@
+Zevio GPIO controller
+
+Required properties:
+- compatible = "lsi,zevio-gpio"
+- reg =
+- #gpio-cells = <2>
+- gpio-controller;
+
+Optional:
+- #ngpios = <32>: Number of GPIOs. Defaults to 32 if
This driver supports the GPIO controller found in LSI ZEVIO SoCs.
It has been successfully tested on a TI nspire CX calculator.
---
.../devicetree/bindings/gpio/gpio-zevio.txt| 18 ++
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile
My Latitude E6510 has the following graphics HW:
01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e200 (32-bit,
This patch splits the sam9x5 peripheral definitions into:
- a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
- several optional peripheral definitions which will be included by specific
sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
This provides a better representation of the real hardware
Hello, Michal.
On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> How is it specific to memcg? The fact only memcg uses the interface
> doesn't imply it is memcg specific.
I don't follow. It's only for memcg. That is *by definition* memcg
specific. It's the verbatim meaning of
Dear,
Our company manufactures a range of injectable and oral steroids products that
are used successfully in over 10 countries.
We are considering expanding our products to new markets and we would
appreciate you assistance.
In particular, we would like to look for product agents. We will quote
On Tue 06-08-13 12:15:09, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
> > I am objecting to moving the generic part of that code into memcg. The
> > memcg part and the additional complexity (all the parsing and conditions
> > for signalling)
> -Original Message-
> From: grund...@google.com [mailto:grund...@google.com] On Behalf Of Grant
> Grundler
> Sent: Wednesday, August 07, 2013 1:07 AM
> To: Marek Szyprowski
>
> Hi Marek,
>
> On Tue, Aug 6, 2013 at 6:17 AM, Marek Szyprowski
> wrote:
> ...
> > IMHO it is much better to
On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov wrote:
> Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
> used as a feature.
>
> Grazvydas, I cc'ed you because I do not really understand
> set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
> with the "Linux 2.6.33+
On Mon, Aug 05, 2013 at 01:15:40PM +0100, Matt Fleming wrote:
> > +static __init int match_config_table(efi_guid_t *guid,
> > +unsigned long table,
> > +efi_config_table_type_t *table_types)
> > +{
> > + u8 str[38];
>
> Shouldn't
v2: added myself as a maintainer
Sorry for previous bad-wrapped email.
ideapad_slidebar is a new driver which enables slidebars on some
Lenovo IdeaPad laptops (the slidebars work with SlideNav/Desktop
Navigator under Windows)
Fixes this: https://bugzilla.kernel.org/show_bug.cgi?id=16004
On 07/08/13 11:54, Namhyung Kim wrote:
> On Wed, 07 Aug 2013 11:19:32 +0300, Adrian Hunter wrote:
>> On 07/08/13 11:09, Namhyung Kim wrote:
>>> On Mon, 5 Aug 2013 19:26:25 +0300, Adrian Hunter wrote:
The size of data retrieved from a sample event must be
validated to ensure it does not
vmlinux maps now map to the dso and the symbol values
are now file offsets. For comparison with kallsyms
the virtual memory address is needed which is obtained
by unmapping the symbol value.
The "vmlinux symtab matches kallsyms" is adjusted
accordingly.
Signed-off-by: Adrian Hunter
---
Hi Huajun,
Sorry for the long delay.
I've been too busy to catch up this new big feature.
Anyway, do you guys still design or focus on this issue?
Nowadays, I can afford to dive into this issue.
So, if you have done any progress so far, can you share it with me?
Otherwise, I'd like to start to
The new "object code reading" test shows that it is not possible
to read object code from vmlinux. That is because the mappings
do not map to the dso. This patch fixes that.
A side-effect of changing the kernel map is that the "reloc"
offset must be taken into account. As a result of that
kallsyms maps now may map to kcore and the symbol values
now may be file offsets. For comparison with vmlinux
the virtual memory address is needed which is obtained
by unmapping the symbol value.
The "vmlinux symtab matches kallsyms" is adjusted
accordingly.
Signed-off-by: Adrian Hunter
---
Currently the symbol name is displayed at the top
when displaying symbol annotation. Add to this
the dso long name.
Signed-off-by: Adrian Hunter
---
tools/perf/ui/browsers/annotate.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git
When kcore is used for annotation, symbols do not
have correct sizes because they come from kallsyms.
That sometimes results in an extra nop being seen
after the end of a function. Remove it.
Signed-off-by: Adrian Hunter
---
tools/perf/util/annotate.c | 31 +++
1
Annotation with /proc/kcore is possible so the logic
is adjusted to allow it. The main difference is that
/proc/kcore had no symbols so the parsing logic needed
a tweak to read jump offsets.
The other difference is that objdump cannot always
read from kcore. That seems to be a bug with objdump.
We want the trig_sts bits to be cleared in all cases where we consider
the jack detection interrupt to have been handled. Specifically, if a
duplicate detection event was suppressed these bits were not cleared
causing the CODEC to not enter a low power state. This patch clears the
bits on the
When removing duplicate symbols, prefer to remove
syscall aliases starting with SyS or compat_SyS.
A side-effect of that is that it results in slightly
improved results for the "vmlinux symtab matches kallsyms"
test.
Signed-off-by: Adrian Hunter
---
tools/perf/util/symbol.c | 17
On 7 August 2013 17:00, Sudeep KarkadaNagesha
wrote:
> Any particular reason we need this check in all drivers after your
> commit: 5a1c0228 "cpufreq: Avoid calling cpufreq driver's target()
> routine if target_freq == policy->cur"
>
> I think it can removed from all drivers, am I missing
kcore has no symbols, so the call target name does not display.
Fix by looking up the symbol name if it is on the same map.
Signed-off-by: Adrian Hunter
---
tools/perf/util/annotate.c | 16
1 file changed, 16 insertions(+)
diff --git a/tools/perf/util/annotate.c
Make the "object code reading" test attempt to read from
kcore.
The test uses objdump which struggles with kcore. i.e.
doesn't always work, sometimes takes a long time.
The test has been made to work around those issues.
Signed-off-by: Adrian Hunter
---
tools/perf/tests/code-reading.c | 100
In the absence of vmlinux, perf tools uses kallsyms
for symbols. If the user has access, now also map to
/proc/kcore.
The dso data_type is now set to either
DSO_BINARY_TYPE__KCORE or DSO_BINARY_TYPE__GUEST_KCORE
as approprite.
This patch breaks the "vmlinux symtab matches kallsyms"
test. That
The new "object code reading" test shows that it is not possible
to read object code from kernel modules. That is because the mappings
do not map to the dsos. This patch fixes that.
This involves identifying and flagging relocatable (ELF type ET_REL) files
(e.g. kernel modules) for symbol
In order to use kernel maps to read object code, those
maps must be adjusted to map to the dso file offset.
Because lazy-initialization is used, that is not done
until symbols are loaded. However the maps are first
used by thread__find_addr_map() before symbols are loaded.
So this patch changes
Using the information in mmap events, perf tools can read object
code associated with sampled addresses. A test is added that
compares bytes read by perf with the same bytes read using
objdump.
Signed-off-by: Adrian Hunter
---
tools/perf/Makefile | 1 +
Hi
Here are some patches that add support for reading object code from vmlinux,
kernel modules and /proc/kcore.
Changes in V4:
perf tools: make it possible to read object code from kernel modules
Fix symbol adjustment for kernel modules
Remove kallsyms'
On Wed, Aug 07 2013, Rusty Russell wrote:
> Christoph Jaeger writes:
>> In param_get_byte(), to which the macro STANDARD_PARAM_DEF(byte, ...)
>> expands,
>> "%c" is used to print an unsigned char. So it gets printed as a character
>> what
>> is not intended here. Use "%hhu" instead.
>>
>>
On 07/08/13 12:22, Viresh Kumar wrote:
> On 7 August 2013 16:46, Amit Daniel Kachhap wrote:
>> This patch fixes the issue of un-necessary setting the clock controller
>> when the new target frequency is same as the current one. This case usually
>> occurs with governors like ondemand which passes
There is no limit for the maximum number of threshold events registered
per memcg. This might lead to an user triggered memory depletion if a
regular user is allowed to register on memory.[memsw.]usage_in_bytes
eventfd interface.
Let's be more strict and cap the number of events that might be
There is no limit for the maximum number of oom_control events
registered per memcg. This might lead to an user triggered memory
depletion if a regular user is allowed to register events.
Let's be more strict and cap the number of events that might be
registered. MAX_OOM_NOTIFY_EVENTS value is
On Wed, Aug 7, 2013 at 1:06 PM, Lars Poeschel wrote:
> From: Lars Poeschel
>
> Following commit ff5c9059 and therefore other omap platforms using
> the gpio-omap driver correct the #interrupt-cells property on am33xx
> too. The omap gpio binding documentaion also states that
> the
There is no limit for the maximum number of vmpressure events registered
per memcg. This might lead to an user triggered memory depletion if a
regular user is allowed to register events.
Let's be more strict and cap the number of events that might be
registered. MAX_VMPRESSURE_EVENTS value is
v2: added myself as a maintainer
ideapad_slidebar is a new driver which enables slidebars on some
Lenovo IdeaPad laptops (the slidebars work with SlideNav/Desktop
Navigator under Windows)
Fixes this: https://bugzilla.kernel.org/show_bug.cgi?id=16004
Registers 'IdeaPad Slidebar' input device
On 7 August 2013 16:46, Amit Daniel Kachhap wrote:
> This patch fixes the issue of un-necessary setting the clock controller
> when the new target frequency is same as the current one. This case usually
> occurs with governors like ondemand which passes the target frequency as the
> percentage of
This patch fixes the issue of un-necessary setting the clock controller
when the new target frequency is same as the current one. This case usually
occurs with governors like ondemand which passes the target frequency as the
percentage of average frequency. This check is present in most of the
In the following patches, we need to call get_ramdisk_{image|size}()
to get initrd file's address and size. So make these two functions
global.
v1 -> v2:
As tj suggested, make these two function static inline in
arch/x86/include/asm/setup.h.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
From: Lars Poeschel
Following commit ff5c9059 and therefore other omap platforms using
the gpio-omap driver correct the #interrupt-cells property on am33xx
too. The omap gpio binding documentaion also states that
the #interrupt-cells property should be 2.
Signed-off-by: Lars Poeschel
---
> -Original Message-
> From: Stanislaw Gruszka [mailto:sgrus...@redhat.com]
> Sent: Tuesday, August 06, 2013 09:55
> To: Winkler, Tomas
> Cc: linux-kernel@vger.kernel.org
> Subject: [3.10 regression] mei endless recursion
>
> Hi
>
> We have a bug report when system fail to boot on 3.10
Linux kernel cannot migrate pages used by the kernel. As a result, hotpluggable
memory used by the kernel won't be able to be hot-removed. To solve this
problem, the basic idea is to prevent memblock from allocating hotpluggable
memory for the kernel at early time, and arrange all hotpluggable
Since we split acpi_table_init() into two steps, and want to do
the two steps separately, we need to do check_multiple_madt() after
acpi_table_init_override().
But we also have to keep acpi_table_init() as before because it
is also used in ia64, we have to do check_multiple_madt() directly
in
As the previous patches split the acpi_gbl_root_table_list initialization
procedure into two steps: install and override, this patch does the "install"
steps earlier, right after memblock is ready.
In this way, we are able to find SRAT in firmware earlier. And then, we can
prevent memblock from
The macro INVALID_TABLE() is defined like this:
#define INVALID_TABLE(x, path, name)\
{ pr_err("ACPI OVERRIDE: " x " [%s%s]\n", path, name); continue; }
And it is used like this:
for (...) {
...
if (...)
The previous patch introduces two new functions:
acpi_tb_root_table_install() and acpi_tb_root_table_override(),
which work just the same as acpi_tb_parse_root_table() if they are
called in sequence.
In order to split acpi_initialize_tables(), call thes two functions
in
Linux cannot migrate pages used by the kernel due to the direct mapping
(va = pa + PAGE_OFFSET), any memory used by the kernel cannot be hot-removed.
So when using memory hotplug, we have to prevent the kernel from using
hotpluggable memory.
The ACPI table SRAT (System Resource Affinity Table)
Hello Richard,
On 07/08/2013 12:38, Richard Genoud wrote:
2013/8/7 Boris BREZILLON :
This patch splits the sam9x5 peripheral definitions into:
- a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
- several optional peripheral definitions which will be included by specific
sam9x5 SoCs
* Chen Baozi [130805 08:33]:
> ping?
>
> On Aug 1, 2013, at 7:27 PM, Chen Baozi wrote:
>
> > The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
> > rather than INCREMENTER_NUMERATOR_OFFSET.
Maybe describe what exactly happens without this fix?
Also we should get few
On Wed, Aug 07, 2013 at 10:36:08AM +, Matthew Garrett wrote:
> Not really. The ACPI driver is able to do this because the events and
> the backlight are associated with the same device.
Well, it doesn't work at least in my case.
I need to echo stuff into /sys/class/backlight/intel_backlight
In the next commit this function will be used in the uio subsystem
Signed-off-by: Uwe Kleine-König
---
Hello,
Greg suggested to take this patch together with the next one via his uio
tree with the appropriate acks.
Best regards
Uwe
mm/memory.c | 1 +
1 file changed, 1 insertion(+)
diff
This makes it possible to let gdb access mappings of the process that is
being debugged.
uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.
Signed-off-by: Uwe Kleine-König
---
drivers/uio/uio.c | 26 +-
1 file
vma_count is used write-only and so fails to be useful. So remove it.
Signed-off-by: Uwe Kleine-König
---
drivers/uio/uio.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index c4279b2..8abe78c 100644
--- a/drivers/uio/uio.c
+++
In acpi_initrd_override(), it checks several things to ensure the
table it found is valid. In later patches, we need to do these check
somewhere else. So this patch introduces a common function
acpi_verify_initrd() to do all these checks, and reuse it in different
places. The function will be used
2013/8/7 boris brezillon :
> Hello Richard,
>
>
> On 07/08/2013 12:38, Richard Genoud wrote:
>>
>> 2013/8/7 Boris BREZILLON :
>>>
>>> This patch splits the sam9x5 peripheral definitions into:
>>> - a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
>>> - several optional peripheral definitions
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info.
The memory affinities in SRAT record every memory range in the
system, and also, flags specifying if the memory range is
hotpluggable.
(Please refer to ACPI spec 5.0 5.2.16)
memblock starts to work at very early time, and SRAT has
The previous patch introduces two new functions:
acpi_initialize_tables_firmware() and acpi_initialize_tables_override(),
which work just the same as acpi_initialize_tables() if they are called
in sequence.
In order to split acpi_table_init() on acpi side, call these two functions
in
The comments of find_cpio_data() says:
* @offset: When a matching file is found, this is the offset to the
* beginning of the cpio. ..
But according to the code,
dptr = PTR_ALIGN(p + ch[C_NAMESIZE], 4);
nptr = PTR_ALIGN(dptr + ch[C_FILESIZE], 4);
*offset =
This patch splits acpi_boot_table_init() into two steps,
so that we can do each step separately in later patches.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
arch/x86/kernel/acpi/boot.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git
This patch splits acpi_tb_parse_root_table() into two steps, and
introduces two new functions:
acpi_tb_root_table_install() and acpi_tb_root_table_override().
They are just the same as acpi_tb_parse_root_table() if they are
called in sequence.
Signed-off-by: Tang Chen
Reviewed-by: Zhang
This patch splits acpi_table_init() into two steps.
Since acpi_table_init() is used not just in x86, also used in ia64,
we introduce two new functions:
acpi_table_init_firmware() and acpi_table_init_override(),
which work just the same as acpi_table_init() if they are called
in sequence. This
There is no flag in memblock to describe what type the memory is.
Sometimes, we may use memblock to reserve some memory for special usage.
And we want to know what kind of memory it is. So we need a way to
differentiate memory for different usage.
In hotplug environment, we want to reserve
This patch introduce early_acpi_firmware_srat() to find the
phys addr of SRAT provided by firmware. And call it in
find_hotpluggable_memory().
Since we have initialized acpi_gbl_root_table_list earlier,
and store all the tables' phys addrs and signatures in it,
it is easy to find the SRAT.
In ACPI SRAT(System Resource Affinity Table), there is a memory affinity for
each
memory range in the system. In each memory affinity, there is a field indicating
that if the memory range is hotpluggable.
This patch parses all the memory affinities in SRAT only, and find out all the
hotpluggable
This patch splits acpi_initialize_tables() into two steps, and
introduces two new functions:
acpi_initialize_tables_firmware() and acpi_tb_root_table_override(),
which work just the same as acpi_initialize_tables() if they are called
in sequence.
Signed-off-by: Tang Chen
Reviewed-by: Zhang
This patch adds a menu item to clocksource' Kconfig file. Without it the
changeable items look somehow lost in the main drivers' menu
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/clocksource/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clocksource/Kconfig
This patch-set aims to solve some problems at system boot time
to enhance memory hotplug functionality.
[Background]
The Linux kernel cannot migrate pages used by the kernel because
of the kernel direct mapping. Since va = pa + PAGE_OFFSET, if the
physical address is changed, we cannot simply
From: Yasuaki Ishimatsu
If system can create movable node which all memory of the node is allocated
as ZONE_MOVABLE, setup_node_data() cannot allocate memory for the node's
pg_data_t. So, use memblock_alloc_try_nid() instead of memblock_alloc_nid()
to retry when the first allocation fails.
At early time, memblock will reserve some memory for the kernel,
such as the kernel code and data segments, initrd file, and so on,
which means the kernel resides in these memory regions.
Even if these memory regions are hotpluggable, we should not
mark them as hotpluggable. Otherwise the kernel
In find_hotpluggable_memory, once we find out a memory region which is
hotpluggable, we want to mark them in memblock.memory. So that we could
control memblock allocator not to allocte hotpluggable memory for the kernel
later.
To achieve this goal, we introduce MEMBLOCK_HOTPLUG flag to indicate
The Hot-Pluggable fired in SRAT specifies which memory is hotpluggable.
As we mentioned before, if hotpluggable memory is used by the kernel,
it cannot be hot-removed. So memory hotplug users may want to set all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use it.
Memory hotplug
Arrange hotpluggable memory as ZONE_MOVABLE will cause NUMA performance down
because the kernel cannot use movable memory. For users who don't use memory
hotplug and who don't want to lose their NUMA performance, they need a way to
disable this functionality. So we improved movablecore boot
On Wed, Aug 07, 2013 at 11:06:19AM +0200, Linus Walleij wrote:
> This macro was invented by Mattias Nilsson for the usecase
> where you want to set a sequence of bits inside a n-bit
> word, while leaving the head and tail of the sequence all
> zeroes. For example:
>
> #include
>
> u16 mask
The Hot-Pluggable field in SRAT suggests if the memory could be
hotplugged while the system is running. Print it as well when
parsing SRAT will help users to know which memory is hotpluggable.
Signed-off-by: Tang Chen
Reviewed-by: Wanpeng Li
Reviewed-by: Zhang Yanfei
Acked-by: Tejun Heo
---
The previous patch introduced two new functions:
acpi_tb_install_table_firmware() and acpi_tb_install_table_override().
They are the same as acpi_tb_install_table() if they are called in sequence.
In order to split acpi_tb_parse_root_table(), we call these two functions
instead of
On Tue, 2013-07-23 at 13:44 -0500, Rob Herring wrote:
> On 07/23/2013 01:09 PM, Ian Campbell wrote:
> > On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:
> >
> >> I think the solution is to introduce some new shared/common location for
> >> shared/common *.dtsi files, into the kernel tree,
According to the related discussion in another thread, this patch can be
obsoleted now.
Thanks.
On 08/06/2013 04:43 PM, Chen Gang wrote:
> Improve the usage of return value, so not only can make code clearer
> to readers, but also can improve the performance.
>
> Assign the return error code
2013/8/7 Boris BREZILLON :
> This patch splits the sam9x5 peripheral definitions into:
> - a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
> - several optional peripheral definitions which will be included by specific
> sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
>
> This provides a better
On Wed, 2013-08-07 at 09:44 +0200, Borislav Petkov wrote:
> Background is that on my x230, I needed to connect the
> Fn-Fx backlight hotkey presses to a script to write to
> /sys/class/backlight/intel_backlight/brightness because Fluxbox doesn't
> do that (and maybe doesn't have to).
>
> So,
On Wed, Aug 07, 2013 at 05:03:15PM +0800, Aaron Lu wrote:
> I think this would require the kernel has the knowledge of which
> backlight interface this system is using or should be using, or it
> wouldn't know which interface should receive and process the event...
Well, we can have a default
On Wed, 2013-08-07 at 11:06 +0200, Linus Walleij wrote:
> This macro was invented by Mattias Nilsson for the usecase
> where you want to set a sequence of bits inside a n-bit
> word, while leaving the head and tail of the sequence all
> zeroes. For example:
>
> #include
BITS is a name that's
It is expected that _nesting == INT_MIN if _nesting < 0.
Add a warning to it if something unexpected happen.
Signed-off-by: Lai Jiangshan
---
kernel/rcutree_plugin.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index
Background)
Although all articles declare that rcu read site is deadlock-immunity.
It is not true for rcu-preempt, it will be deadlock if rcu read site
overlaps with scheduler lock.
ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
is still not deadlock-immunity. And the
601 - 700 of 1724 matches
Mail list logo
