On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
> On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
>> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
>> > On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
>> > > On Wed, Sep 26, 2012 at 09:45:43AM -0700,
On Sun, Sep 30, 2012 at 12:05 PM, Jean Delvare wrote:
> On Sun, 30 Sep 2012 11:35:41 +0200, Geert Uytterhoeven wrote:
>> On Sun, Sep 30, 2012 at 11:20 AM, Jean Delvare wrote:
>> > On Sun, 30 Sep 2012 11:08:41 +0200, Geert Uytterhoeven wrote:
>> >> On Sun, Sep 30, 2012 at 10:53 AM, Jean Delvare
On Sun, Sep 30, 2012 at 10:18:17AM +0200, Avi Kivity wrote:
> On 09/28/2012 08:16 AM, Raghavendra K T wrote:
> >
> >>
> >> +struct pv_sched_info {
> >> + unsigned long sched_bitmap;
> >
> > Thinking, whether we need something similar to cpumask here?
> > Only thing is we are
Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC
warnings:
drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_rhba’:
drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is above
array bounds [-Warray-bounds]
drivers/scsi/qla2xxx/qla_gs.c: In function
On 30/09/12 11:35, Stijn Devriendt wrote:
> In our kernel tree we have similar code. If you like I can request
> permission
> to share. I can, however, already give you an update on the basic
> structure, perhaps
> it's useful now.
>
> For the first part, the drivers need to implement a the gpio
Hello, James.
On Sun, Sep 30, 2012 at 09:56:28AM +0100, James Bottomley wrote:
> The beancounter approach originally used by OpenVZ does exactly this.
> There are two specific problems, though, firstly you can't count
> references in generic code, so now you have to extend the cgroup
> tentacles
Dear Axel Lin,
On Sun, 30 Sep 2012 16:23:27 +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin
> ---
> drivers/gpio/gpio-mvebu.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index 902af43..7a874129 100644
> ---
On 29/09/12 21:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Problem here is that it's only an intermediate format since hardware
>> often needs special preparation of the data.
>>
>> But will evaluate what makes most sense.
> the key point here is to avoid to manipualte data each time we call
>
Otherwise, we got NULL derefernce while calling backlight_device_unregister()
in tps65217_bl_remove().
Also convert to use module_platform_driver.
Signed-off-by: Axel Lin
---
drivers/video/backlight/tps65217_bl.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff
Building regmap.o triggers this GCC warning:
drivers/base/regmap/regmap.c: In function ‘regmap_raw_read’:
drivers/base/regmap/regmap.c:1172:6: warning: ‘ret’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
It seems 'ret' should always be set when this function returns.
On Sun, 30 Sep 2012 11:35:41 +0200, Geert Uytterhoeven wrote:
> On Sun, Sep 30, 2012 at 11:20 AM, Jean Delvare wrote:
> > On Sun, 30 Sep 2012 11:08:41 +0200, Geert Uytterhoeven wrote:
> >> On Sun, Sep 30, 2012 at 10:53 AM, Jean Delvare wrote:
> >> > I thought we were trying to move away from
On Tue, Sep 25, 2012 at 9:05 AM, Dan Carpenter wrote:
> copy_from_user() returns the number of bytes remaining to be copied, but
> we want to return an error code here.
>
> Signed-off-by: Dan Carpenter
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Hi,
I'd like to confirm this bug exists in 3.6-rc7 32-bit. It seems to occur
only when opening the audio output, and not with every audio player. MP3
/ Ogg playback with VLC via Pulseaudio triggers the noise. Xine, Totem
don't. After about 20 to 40 seconds, it suddenly disappears.
On Tue, Sep 25, 2012 at 9:02 AM, Dan Carpenter wrote:
> snprintf() returns the number of characters which would have been
> printed if there were enough space. For example, on the first print if
> we fill up the 28 character string then it would return a number more
> than 30. Use scnprintf()
On Thu, Sep 27, 2012 at 11:22 PM, Roland Stigge wrote:
>
> The recurring task of providing simultaneous access to GPIO lines
> (especially
> for bit banging protocols) needs an appropriate API.
>
> This patch adds a kernel internal "Block GPIO" API that enables
> simultaneous
> access to several
Hi,
there seems to be a bug in either ext4 or VM code triggered with 16 GB
memory when compiled with 32-bit and PAE. dirty_background_ratio
defaults to 10, dirty_ratio to 20. But in effect, dirty pages are
strongly limited (zero or negative?). I observed extreme I/O wait states
and slow disk
On Sun, Sep 30, 2012 at 11:20 AM, Jean Delvare wrote:
> On Sun, 30 Sep 2012 11:08:41 +0200, Geert Uytterhoeven wrote:
>> On Sun, Sep 30, 2012 at 10:53 AM, Jean Delvare wrote:
>> > I thought we were trying to move away from explicit arch exclusions,
>> > but if S390 is special then fine with me.
On Tue, Sep 25, 2012 at 9:01 AM, Dan Carpenter wrote:
> We only need to allocate mapping if there is an rproc domain.
>
> Signed-off-by: Dan Carpenter
> ---
> Static checker stuff. Handle with appropriate caution.
Applied, thanks.
I'm just changing the subject, because this actually fixes a
On Sun, 30 Sep 2012 11:08:41 +0200, Geert Uytterhoeven wrote:
> On Sun, Sep 30, 2012 at 10:53 AM, Jean Delvare wrote:
> > I thought we were trying to move away from explicit arch exclusions,
> > but if S390 is special then fine with me. I've folded Heiko's fix into
>
> "depends on
On Sun, Sep 30, 2012 at 10:53 AM, Jean Delvare wrote:
> On Sat, 29 Sep 2012 18:39:13 +0200, Geert Uytterhoeven wrote:
>> On Thu, Sep 27, 2012 at 1:51 PM, Heiko Carstens
>> > From 24c68e72b6198b8412a8605fac7d9c90796502ac Mon Sep 17 00:00:00 2001
>> > From: Heiko Carstens
>> > Date: Thu, 27 Sep
On Sun, 2012-09-30 at 17:02 +0900, Tejun Heo wrote:
> On Sun, Sep 30, 2012 at 04:57:00PM +0900, Tejun Heo wrote:
> > On Thu, Sep 27, 2012 at 10:45:01PM +0400, Glauber Costa wrote:
> > > > Can you please give other examples of cases where this type of issue
> > > > exists (plenty of shared kernel
Hello, Viresh.
On Thu, Sep 27, 2012 at 02:34:05PM +0530, Viresh Kumar wrote:
> - A cpu has programmed a timer and is IDLE now.
> - CPU gets into interrupt handler due to timer and queues a work. As the CPU
> is
> currently IDLE, we can queue this work to some other CPU.
I'm still a bit
On Sat, 29 Sep 2012 18:39:13 +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 27, 2012 at 1:51 PM, Heiko Carstens
> > From 24c68e72b6198b8412a8605fac7d9c90796502ac Mon Sep 17 00:00:00 2001
> > From: Heiko Carstens
> > Date: Thu, 27 Sep 2012 13:37:14 +0200
> > Subject: [PATCH] i2c: Make I2C
Hello, Michal.
On Thu, Sep 27, 2012 at 05:09:50PM +0200, Michal Hocko wrote:
> On Thu 27-09-12 07:33:00, Tejun Heo wrote:
> > I'm not too convinced. First of all, the overhead added by kmemcg
> > isn't big.
>
> You are probably talking about memory overhead which is indeed not that
> big
On Sun, Sep 30, 2012 at 04:23:27PM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin
> ---
> drivers/gpio/gpio-mvebu.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index 902af43..7a874129 100644
> ---
The latest maintenance release Git v1.7.12.2 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
277b759139ddb62c6935da37de8a483e2c234a97 git-1.7.12.2.tar.gz
On Thu, Sep 27, 2012 at 9:43 AM, Ulf Hansson wrote:
> In my case for ux500 we use the mmci host driver. It is an ARM cross
> SoC device driver, and I believe adding clock notifiers in the driver
> to handle the voltage scale would complicate things quite a bit. It
> seems a lot easier to let the
On Tue, Sep 25, 2012 at 12:10 AM, Randy Dunlap wrote:
> on x86_64:
>
> drivers/built-in.o: In function `rproc_virtio_finalize_features':
> remoteproc_virtio.c:(.text+0x2f9a02): undefined reference to
> `vring_transport_features'
> drivers/built-in.o: In function `rproc_virtio_del_vqs':
>
On Fri, Sep 28, 2012 at 03:34:19PM +0400, Glauber Costa wrote:
> On 09/27/2012 05:44 PM, Michal Hocko wrote:
> > Anyway, I have just noticed that __mem_cgroup_try_charge does
> > VM_BUG_ON(css_is_removed(>css)) on a given memcg so you should
> > keep css ref count up as well.
>
> IIRC, css_get
On Wed, Sep 26, 2012 at 3:46 AM, Neil Zhang wrote:
> We need to return 0 or 1 when get gpio value.
>
> Signed-off-by: Neil Zhang
Aha there is another patch fixing that comment I had, sorry, going through
the mail backlog.
But you need to take Haojian's comments into account so I'm not
On Tue, Sep 25, 2012 at 2:03 PM, Neil Zhang wrote:
> We need to return 0 or 1 when get gpio value.
OK...
> static int pxa_gpio_get(struct gpio_chip *chip, unsigned offset)
> {
> - return readl_relaxed(gpio_chip_base(chip) + GPLR_OFFSET) & (1 <<
> offset);
> + u32 gplr =
On Tue, Sep 25, 2012 at 9:56 AM, Roland Stigge wrote:
> This patch adds documentation for set_debounce in struct device_node.
>
> Signed-off-by: Roland Stigge
Applied, thanks!
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Sep 25, 2012 at 9:56 AM, Roland Stigge wrote:
> This patch adds the missing gpi28 to the list of GPIOs in the GPI P3 "chip".
>
> NOTE: This patch depends on incrementing LPC32XX_GPI_P3_MAX. When applied
> without the respective mach-lpc32xx patch (merged via arm-soc.git), gcc will
>
On 09/28/2012 01:40 PM, Andrew Theurer wrote:
>>
>> >>
>> >> IIRC, with defer preemption :
>> >> we will have hook in spinlock/unlock path to measure depth of lock held,
>> >> and shared with host scheduler (may be via MSRs now).
>> >> Host scheduler 'prefers' not to preempt lock holding vcpu.
Hello, Glauber.
On Thu, Sep 27, 2012 at 10:30:36PM +0400, Glauber Costa wrote:
> > But that happens only when pages enter and leave slab and if it still
> > is significant, we can try to further optimize charging. Given that
> > this is only for cases where memcg is already in use and we provide
Signed-off-by: Axel Lin
---
drivers/gpio/gpio-mvebu.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 902af43..7a874129 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -381,11 +381,13 @@ static int
On 09/28/2012 08:16 AM, Raghavendra K T wrote:
>
>>
>> +struct pv_sched_info {
>> + unsigned long sched_bitmap;
>
> Thinking, whether we need something similar to cpumask here?
> Only thing is we are representing guest (v)cpumask.
>
DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)
On 09/28/2012 08:18 PM, Konrad Rzeszutek Wilk wrote:
>> >> PLE:
>> >> - works for unmodified / non-Linux guests
>> >> - works for all types of spins (e.g. smp_call_function*())
>> >> - utilizes an existing hardware interface (PAUSE instruction) so likely
>> >> more robust compared to a software
on 09/26/2012 08:41 AM Thanasis wrote the following:
> on 09/25/2012 11:53 PM Francois Romieu wrote the following:
>> Thanasis :
>> [...]
>>> Ping failed in the following step:
>>>
>>> HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its
>>> rtl_hw_start callers.
>>
>> *spleen*
>>
>>
On Sun, Sep 30, 2012 at 04:57:00PM +0900, Tejun Heo wrote:
> On Thu, Sep 27, 2012 at 10:45:01PM +0400, Glauber Costa wrote:
> > > Can you please give other examples of cases where this type of issue
> > > exists (plenty of shared kernel data structure which is inherent to
> > > the workload at
memblock_x86_fill() could double memory array.
If we set max_pfn_mapped to 512M, so memory array could be around 512M.
So kdump will not get big range (like 512M) under 1024M.
Try to put it down under 1M, it could use about 4k or so.
Also we need this one when we try to only map ram range only
It should take physical address range that will need to be mapped.
find_early_table_space should take range that pgt buff should be in.
Separating page table size calculating and finding early page table will
reduce confusing.
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
Now we pass around use_gbpages and use_pse for calculating page table size,
Later we will need to calculate page table size for every ram range, that
mean those calculation will be done several times.
Those info are the same for all ram range and could be stored in page_size_mask
and only probe
So make init_memory_mapping smaller and readable.
Suggested-by: Ingo Molnar
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/mm/init.c | 42 ++
1 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/init.c
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
|regression since 2.6.39, namely the machine reboots
From: Jacob Shin
There could be cases where user supplied memmap=exactmap memory
mappings do not mark the region where the kernel .text .data and
.bss reside as E820_RAM, as reported here:
https://lkml.org/lkml/2012/8/14/86
Handle it by complaining, and adding the range back into the e820.
We should not do that in every calling of init_memory_mapping.
At the same time need to move down early_memtest, and could move after_bootmem
checking away.
-v2: fix one early_memtest with 32bit by passing max_pfn_mapped instead.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c | 72
From: Jacob Shin
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
-v2: change applying sequence to keep git bisecting working.
so add dummy pfn_range_is_mapped(). - Yinghai
From: Jacob Shin
Currently direct mappings are created for [ 0 to max_low_pfn<
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/include/asm/page_types.h |8 +--
arch/x86/kernel/setup.c |8 ++-
arch/x86/mm/init.c| 119
So later could make it call split_mem_range.
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/mm/init.c | 116 ++--
1 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index
They all need to go over ram range in same sequence. So add shared function
to reduce duplicated code.
-v2: Change to walk_ram_ranges() according to Pekka Enberg.
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/mm/init.c | 64
From: Jacob Shin
Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()
This patch also reportedly fixes suspend/resume
Now init_memory_mapping is called two times, later will call more time for
more ram ranges.
Could put all related init_mem calling together.
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/include/asm/init.h|1 -
arch/x86/include/asm/pgtable.h |2 +-
Current kernel init memory mapping between [0, TOML) and [4G, TOMH)
Some AMD systems have mem hole between 4G and TOMH, around 1T.
According to HPA, we should only mapping ram range.
This patcheset:
1. Seperate calculate_table_space_size and find_early_page_table out with
init_memory_mapping.
Hello, Glauber.
On Thu, Sep 27, 2012 at 10:45:01PM +0400, Glauber Costa wrote:
> > Can you please give other examples of cases where this type of issue
> > exists (plenty of shared kernel data structure which is inherent to
> > the workload at hand)? Until now, this has been the only example for
Hello,
On Fri, Sep 28, 2012 at 06:04:01PM +0800, Lai Jiangshan wrote:
> On 09/27/2012 02:24 AM, Tejun Heo wrote:
> > On Thu, Sep 27, 2012 at 01:20:34AM +0800, Lai Jiangshan wrote:
> >> There is no reason to use WORKER_PREP, remove it from rescuer.
> >>
> >> And there is no reason to set it so
Hello,
On Fri, Sep 28, 2012 at 05:52:02PM +0800, Lai Jiangshan wrote:
> Main reason: I think the readability of your is the same as mine,
> and your add two lines.
>
> Tiny reason: my code uses only one return. (I don't always keep one return,
> but I try to keep it if it is still clean)
>
> Is
Hello, Lai.
On Fri, Sep 28, 2012 at 04:06:48PM +0800, Lai Jiangshan wrote:
> But does we need a stand-alone workqueue for work_on_cpu() as it is original
> introduced? (2d3854a3)
Given how work_on_cpu() is used currently, I don't think we need that.
What we need to do is removing the remaining
On Sun, Sep 30, 2012 at 09:38:45AM +0530, anish kumar wrote:
> On Sat, 2012-09-29 at 10:13 +0300, Dan Carpenter wrote:
> > psy->properties is an enum (32 bit type) so adding sizeof() puts us
> > four times further along than we intended. It should be cast to a char
> > pointer before doing the
[Was: Re: [GIT pull] timer fixes for 3.4]
[CC+=Trevor Woerner, after an independent mail led me to find this thread.]
[CC+=linux-api@, which really should have been CCed on the original patch]
Linus,
On Fri, Apr 13, 2012 at 12:19 AM, Linus Torvalds
wrote:
> On Thu, Apr 12, 2012 at 3:06 PM,
From: Nicholas Bellinger
This patch converts iscsi_target_seq_pdu_list.c code for DataSequenceInOrder=No
+
DataPDUInOrder=No operation to honor the MaxXmitDataSegmentLength value
for iscsi_cmd->se_cmd.data_direction == DMA_TO_DEVICE cases.
Cc: Mike Christie
Cc: Andy Grover
Cc: Hannes
From: Nicholas Bellinger
This patch re-adds the ability to optionally run in buffered FILEIO mode
(eg: w/o O_DSYNC) for device backends in order to once again use the
Linux buffered cache as a write-back storage mechanism.
This logic was originally dropped with mainline v3.5-rc commit:
commit
From: Nicholas Bellinger
This patch activates MaxXmitDataSegmentLength usage that performs the
following sequence of events:
- Once the incoming initiator's MAXRECVDATASEGMENTLENGTH key is detected
within iscsi_check_acceptor_state(), save the requested MRDSL into
From: Nicholas Bellinger
The iSCSI TMR TASK_REASSIGN completion logic in iscsi_tmr_task_reassign()
does an explict check for MRDSL across task reassignment, so go ahead and
add an explict MaxXmitDataSegmentLength check here as well to be safe.
Cc: Mike Christie
Cc: Andy Grover
Cc: Hannes
From: Nicholas Bellinger
Now that iscsi-target supports a local configurable MaxXmitDataSegmentLength,
go ahead and make ISCSI_OP_SCSI_CMD, ISCSI_OP_SCSI_DATA_OUT, ISCSI_OP_NOOP_OUT
and ISCSI_OP_TEXT PDU payload checks honor conn_ops->MaxXmitDataSegmentLength.
Cc: Mike Christie
Cc: Andy Grover
From: Nicholas Bellinger
This patch introduces a new per connection MaxXmitDataSegmentLength
parameter value used to represent the outgoing MaxRecvDataSegmentLength
that is actually sent over the wire during iSCSI login response back
to the initiator side.
It also adds a new
From: Nicholas Bellinger
Hi folks,
This following series is destined for v3.7-rc1 code, and re-adds support for
buffered FILEIO + emulate_write_cache=1 emulation removed in v3.5, as well as
fixing up a long standing issue wrt to MaxRecvDataSegmentLength handling within
iscsi-target code.
The
From: Nicholas Bellinger n...@linux-iscsi.org
Hi folks,
This following series is destined for v3.7-rc1 code, and re-adds support for
buffered FILEIO + emulate_write_cache=1 emulation removed in v3.5, as well as
fixing up a long standing issue wrt to MaxRecvDataSegmentLength handling within
From: Nicholas Bellinger n...@linux-iscsi.org
This patch introduces a new per connection MaxXmitDataSegmentLength
parameter value used to represent the outgoing MaxRecvDataSegmentLength
that is actually sent over the wire during iSCSI login response back
to the initiator side.
It also adds a new
From: Nicholas Bellinger n...@linux-iscsi.org
Now that iscsi-target supports a local configurable MaxXmitDataSegmentLength,
go ahead and make ISCSI_OP_SCSI_CMD, ISCSI_OP_SCSI_DATA_OUT, ISCSI_OP_NOOP_OUT
and ISCSI_OP_TEXT PDU payload checks honor conn_ops-MaxXmitDataSegmentLength.
Cc: Mike
From: Nicholas Bellinger n...@linux-iscsi.org
The iSCSI TMR TASK_REASSIGN completion logic in iscsi_tmr_task_reassign()
does an explict check for MRDSL across task reassignment, so go ahead and
add an explict MaxXmitDataSegmentLength check here as well to be safe.
Cc: Mike Christie
From: Nicholas Bellinger n...@linux-iscsi.org
This patch activates MaxXmitDataSegmentLength usage that performs the
following sequence of events:
- Once the incoming initiator's MAXRECVDATASEGMENTLENGTH key is detected
within iscsi_check_acceptor_state(), save the requested MRDSL into
From: Nicholas Bellinger n...@linux-iscsi.org
This patch converts iscsi_target_seq_pdu_list.c code for DataSequenceInOrder=No
+
DataPDUInOrder=No operation to honor the MaxXmitDataSegmentLength value
for iscsi_cmd-se_cmd.data_direction == DMA_TO_DEVICE cases.
Cc: Mike Christie
From: Nicholas Bellinger n...@linux-iscsi.org
This patch re-adds the ability to optionally run in buffered FILEIO mode
(eg: w/o O_DSYNC) for device backends in order to once again use the
Linux buffered cache as a write-back storage mechanism.
This logic was originally dropped with mainline
[Was: Re: [GIT pull] timer fixes for 3.4]
[CC+=Trevor Woerner, after an independent mail led me to find this thread.]
[CC+=linux-api@, which really should have been CCed on the original patch]
Linus,
On Fri, Apr 13, 2012 at 12:19 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu,
On Sun, Sep 30, 2012 at 09:38:45AM +0530, anish kumar wrote:
On Sat, 2012-09-29 at 10:13 +0300, Dan Carpenter wrote:
psy-properties is an enum (32 bit type) so adding sizeof() puts us
four times further along than we intended. It should be cast to a char
pointer before doing the math.
You
Hello, Lai.
On Fri, Sep 28, 2012 at 04:06:48PM +0800, Lai Jiangshan wrote:
But does we need a stand-alone workqueue for work_on_cpu() as it is original
introduced? (2d3854a3)
Given how work_on_cpu() is used currently, I don't think we need that.
What we need to do is removing the remaining
Hello,
On Fri, Sep 28, 2012 at 05:52:02PM +0800, Lai Jiangshan wrote:
Main reason: I think the readability of your is the same as mine,
and your add two lines.
Tiny reason: my code uses only one return. (I don't always keep one return,
but I try to keep it if it is still clean)
Is there
Hello,
On Fri, Sep 28, 2012 at 06:04:01PM +0800, Lai Jiangshan wrote:
On 09/27/2012 02:24 AM, Tejun Heo wrote:
On Thu, Sep 27, 2012 at 01:20:34AM +0800, Lai Jiangshan wrote:
There is no reason to use WORKER_PREP, remove it from rescuer.
And there is no reason to set it so early in
Hello, Glauber.
On Thu, Sep 27, 2012 at 10:45:01PM +0400, Glauber Costa wrote:
Can you please give other examples of cases where this type of issue
exists (plenty of shared kernel data structure which is inherent to
the workload at hand)? Until now, this has been the only example for
Current kernel init memory mapping between [0, TOML) and [4G, TOMH)
Some AMD systems have mem hole between 4G and TOMH, around 1T.
According to HPA, we should only mapping ram range.
This patcheset:
1. Seperate calculate_table_space_size and find_early_page_table out with
init_memory_mapping.
Now init_memory_mapping is called two times, later will call more time for
more ram ranges.
Could put all related init_mem calling together.
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
---
arch/x86/include/asm/init.h|1 -
From: Jacob Shin jacob.s...@amd.com
Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()
This patch also reportedly
They all need to go over ram range in same sequence. So add shared function
to reduce duplicated code.
-v2: Change to walk_ram_ranges() according to Pekka Enberg.
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
---
arch/x86/mm/init.c | 64
So later could make it call split_mem_range.
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
---
arch/x86/mm/init.c | 116 ++--
1 files changed, 58 insertions(+), 58 deletions(-)
diff --git
From: Jacob Shin jacob.s...@amd.com
Currently direct mappings are created for [ 0 to max_low_pfnPAGE_SHIFT )
and [ 4GB to max_pfnPAGE_SHIFT ), which may include regions that are not
backed by actual DRAM. This is fine for holes under 4GB which are covered
by fixed and variable range MTRRs to be
From: Jacob Shin jacob.s...@amd.com
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
-v2: change applying sequence to keep git bisecting working.
so add dummy
We should not do that in every calling of init_memory_mapping.
At the same time need to move down early_memtest, and could move after_bootmem
checking away.
-v2: fix one early_memtest with 32bit by passing max_pfn_mapped instead.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
From: Jacob Shin jacob.s...@amd.com
There could be cases where user supplied memmap=exactmap memory
mappings do not mark the region where the kernel .text .data and
.bss reside as E820_RAM, as reported here:
https://lkml.org/lkml/2012/8/14/86
Handle it by complaining, and adding the range back
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 (x86-64, mm: Put early page table high) causes a S4
|regression since 2.6.39, namely the machine reboots
So make init_memory_mapping smaller and readable.
Suggested-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
---
arch/x86/mm/init.c | 42 ++
1 files changed, 26 insertions(+), 16
Now we pass around use_gbpages and use_pse for calculating page table size,
Later we will need to calculate page table size for every ram range, that
mean those calculation will be done several times.
Those info are the same for all ram range and could be stored in page_size_mask
and only probe
It should take physical address range that will need to be mapped.
find_early_table_space should take range that pgt buff should be in.
Separating page table size calculating and finding early page table will
reduce confusing.
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka
memblock_x86_fill() could double memory array.
If we set max_pfn_mapped to 512M, so memory array could be around 512M.
So kdump will not get big range (like 512M) under 1024M.
Try to put it down under 1M, it could use about 4k or so.
Also we need this one when we try to only map ram range only
On Sun, Sep 30, 2012 at 04:57:00PM +0900, Tejun Heo wrote:
On Thu, Sep 27, 2012 at 10:45:01PM +0400, Glauber Costa wrote:
Can you please give other examples of cases where this type of issue
exists (plenty of shared kernel data structure which is inherent to
the workload at hand)? Until
on 09/26/2012 08:41 AM Thanasis wrote the following:
on 09/25/2012 11:53 PM Francois Romieu wrote the following:
Thanasis thana...@asyr.hopto.org :
[...]
Ping failed in the following step:
HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its
rtl_hw_start callers.
*spleen*
It's
On 09/28/2012 08:18 PM, Konrad Rzeszutek Wilk wrote:
PLE:
- works for unmodified / non-Linux guests
- works for all types of spins (e.g. smp_call_function*())
- utilizes an existing hardware interface (PAUSE instruction) so likely
more robust compared to a software interface
PV:
-
On 09/28/2012 08:16 AM, Raghavendra K T wrote:
+struct pv_sched_info {
+ unsigned long sched_bitmap;
Thinking, whether we need something similar to cpumask here?
Only thing is we are representing guest (v)cpumask.
DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)
cpumask is
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/gpio/gpio-mvebu.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 902af43..7a874129 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -381,11
Hello, Glauber.
On Thu, Sep 27, 2012 at 10:30:36PM +0400, Glauber Costa wrote:
But that happens only when pages enter and leave slab and if it still
is significant, we can try to further optimize charging. Given that
this is only for cases where memcg is already in use and we provide a
101 - 200 of 334 matches
Mail list logo
