headers
Yang Honggang(Joseph | 1 Dec 2011 01:09
Picon

clocksource.c "margin"

Hi John Stultz,
I'm very sorry to trouble you. A problem puzzled me when I reading your 
code in kernel/time/clocksource.c.
In the following functions, your said in the comments that >>5 was used 
to leave a margin of 12.5%.
I don't know how to get the result. I think is should be >> 3 in order 
to leave a margin of 12.5%.
The operation of >> 5 only left 3.125% margin.

__clocksource_updatefreq_scale
...
sec = (cs->mask - (cs->mask >> 5));
...
clocksource_max_deferment
...
     /*
      * To ensure that the clocksource does not wrap whilst we are idle,
      * limit the time the clocksource can be deferred by 12.5%. Please
      * note a margin of 12.5% is used because this can be computed with
      * a shift, versus say 10% which would require division.
      */
     return max_nsecs - (max_nsecs >> 5);
...

Best regards,
Joseph
Permalink | Reply | 1 comment |
headers
Jan Kara | 1 Dec 2011 01:03
Picon

Re: [dm-devel] [PATCH] deadlock with suspend and quotas

On Wed 30-11-11 11:53:40, Mikulas Patocka wrote:
> 
> 
> On Wed, 30 Nov 2011, Alasdair G Kergon wrote:
> 
> > On Tue, Nov 29, 2011 at 11:19:01AM +0100, Jan Kara wrote:
> > > So I believe the consensus was that we should not block sync or flusher
> 
> Well, I think that not blocking sync actually doesn't help at all.
> 
> Suppose at first that you have a perfectly-barriered filesystem --- that 
> is filesystem, that contains barriers around all code paths that could 
> possibly create dirty data. In this case it is impossible to have dirty 
> data while the filesystem is suspended. --- In this case you can call 
> sync on suspened filesystem as much as you like, sync never finds ady 
> dirty data, consequently it never tries to write anything and it can't 
> deadlock. So skipping sync has no effect.
> 
> Suppose as a second case that you have imperfectly-barriered filesystem 
> --- that means there exists a code path that creates dirty data while the 
> filesystem is suspended. In this case if you skip sync, you are violating 
> sync semantics, because the application can create dirty data while 
> suspended, call sync while still suspended and assume that the dirty data 
> was written.
  Except that currently we are in situation c) with e.g. ext4 and xfs. We
have perfectly-barriered filesystem *but* there are dirty bits set in this
filesystem although we are certain there are no dirty data. This
inconsistency between dirty bits and fact whether a page contains dirty
data is due to way how page faults are handled. I've already tried to
explain this in this thread in https://lkml.org/lkml/2011/11/29/109 but
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Dec 2011 01:11

Re: [PATCH] specific do_timer_cpu value for nohz off mode

On Wed, 30 Nov 2011 09:29:59 -0600
Dimitri Sivanich <sivanich <at> sgi.com> wrote:

> +static ssize_t sysfs_store_do_timer_cpu(struct sys_device *dev,
> +						struct sysdev_attribute *attr,
> +						const char *buf, size_t size)
> +{
> +	struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
> +	unsigned int new;
> +	int rv;
> +
> +#ifdef CONFIG_NO_HZ
> +	/* nohz mode not supported */
> +	if (tick_nohz_enabled)
> +		return -EINVAL;
> +#endif
> +
> +	rv = kstrtouint(buf, 0, &new);
> +	if (rv)
> +		return rv;
> +
> +	if (new >= NR_CPUS || !cpu_online(new))
> +		return -ERANGE;
> +
> +	*(unsigned int *)(ea->var) = new;
> +	return size;
> +}

checkpatch tells us:
(Continue reading)

Permalink | Reply | 12 comments |
headers
Andrew Morton | 1 Dec 2011 01:16

Re: [PATCH] specific do_timer_cpu value for nohz off mode

On Wed, 30 Nov 2011 16:11:31 -0800
Andrew Morton <akpm <at> linux-foundation.org> wrote:

> On Wed, 30 Nov 2011 09:29:59 -0600
> Dimitri Sivanich <sivanich <at> sgi.com> wrote:
> 
> > +static ssize_t sysfs_store_do_timer_cpu(struct sys_device *dev,
> > +						struct sysdev_attribute *attr,
> > +						const char *buf, size_t size)
> > +{
> > +	struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
> > +	unsigned int new;
> > +	int rv;
> > +
> > +#ifdef CONFIG_NO_HZ
> > +	/* nohz mode not supported */
> > +	if (tick_nohz_enabled)
> > +		return -EINVAL;
> > +#endif
> > +
> > +	rv = kstrtouint(buf, 0, &new);
> > +	if (rv)
> > +		return rv;
> > +
> > +	if (new >= NR_CPUS || !cpu_online(new))
> > +		return -ERANGE;
> > +
> > +	*(unsigned int *)(ea->var) = new;
> > +	return size;
> > +}
(Continue reading)

Permalink | Reply | 7 comments |
headers
Darren Hart | 1 Dec 2011 01:19
Picon

[PATCH] trace-cmd: Cross-compile fixes for LDFLAGS and include path

Add ability for the Makefile to respect LDFLAGS.
Also remove hardcoded /usr/local/include include path.

Signed-off-by: Richard Purdie <richard.purdie <at> linuxfoundation.org>
Signed-off-by: Darren Hart <dvhart <at> linux.intel.com>

---
 Makefile |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: git/Makefile
===================================================================
--- git.orig/Makefile
+++ git/Makefile
 <at>  <at>  -202,12 +202,13  <at>  <at>  export Q VERBOSE
 TRACECMD_VERSION = $(TC_VERSION).$(TC_PATCHLEVEL).$(TC_EXTRAVERSION)
 KERNELSHARK_VERSION = $(KS_VERSION).$(KS_PATCHLEVEL).$(KS_EXTRAVERSION)

-INCLUDES = -I. -I/usr/local/include $(CONFIG_INCLUDES)
+INCLUDES = -I. $(CONFIG_INCLUDES)

 include features.mk

 # Set compile option CFLAGS if not set elsewhere
 CFLAGS ?= -g -Wall
+LDFLAGS ?=

 ifndef NO_PTRACE
 ifneq ($(call try-cc,$(SOURCE_PTRACE),),y)
 <at>  <at>  -251,7 +252,7  <at>  <at>  do_fpic_compile =					\
(Continue reading)

Permalink | Reply | 1 comment |
headers
Woody Suwalski | 1 Dec 2011 01:24
Picon

Re: [PATCH] init/do_mounts.c : Create /root if it does not exits

Andrew Morton wrote:
> On Sat, 26 Nov 2011 08:34:18 +0000
> yanhong<tempname2 <at> hotmail.com>  wrote:
>
>> From: YanHong<tempname2 <at> hotmail.com>
>>
>> If someone supplies an initramfs without /root in it, and we fail to execute rdinit, we will try to mount
root device and fail, for the mount point does not exits.
>>
>> But we get error message "VFS: Cannot open root device". It's confusing.
>>
>> We can give more detailed error message, or we can go further: if /root does not exits,  create one.
>>
> I really don't know enough about initramfs usage to know if this is a
> good or bad thing.  Can anyone else comment?
>
>> --- a/init/do_mounts.c
>> +++ b/init/do_mounts.c
>>  <at>  <at>  -350,6 +350,9  <at>  <at>  void __init mount_block_root(char *name, int flags)
>>          const char *b = name;
>>   #endif
>>
>> +       if (sys_access((const char __user *) "/root", 0) != 0)
>> +               sys_mkdir((const char __user *) "/root", 0700);
>> +
>>          get_fs_names(fs_names);
>>   retry:
>>          for (p = fs_names; *p; p += strlen(p)+1) {
> I suppose we could remove the sys_access() check and just run mkdir(),
> which will fail to do anything if /root already exists.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Cromie | 1 Dec 2011 01:26
Picon

Re: [PATCH 04/25] dynamic_debug: make dynamic-debug supersede DEBUG ccflag

On Wed, Nov 30, 2011 at 3:16 PM, Joe Perches <joe <at> perches.com> wrote:
> On Wed, 2011-11-30 at 17:03 -0500, Jason Baron wrote:
>> I think it's this patach that is causing a lot of "=p" when I boot up
>> using a 'make defconfig'.
>
> =p?
>

Thats referring to the new enabled indicator in control,
its more greppable than plain old 'p', and has better memonics
(p-flag is set)

root <at> voyage:~# grep =p /dbg/dynamic_debug/control
fs/sysfs/mount.c:66 [mount]sysfs_fill_super =p "%s: could not get root
dentry!\012"
fs/sysfs/mount.c:59 [mount]sysfs_fill_super =p "sysfs: could not get
root inode\012"
drivers/rtc/class.c:102 [rtc_core]rtc_resume =p "%s:  time travel!\012"
drivers/rtc/class.c:94 [rtc_core]rtc_resume =p "%s:  bogus resume time\012"

>>  I'm a bit surprised at how many files have
>> 'DEBUG' defined.
>

thats at least partly due to defconfig
I turn on a few things via bootline and /etc/modprobe.d/dyndbg.conf

handy for seeing boot-time dyndbg processing,
you;ll want to turn it off before catting control..
 dynamic_debug.verbose=1
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brown | 1 Dec 2011 01:29
Gravatar

[PATCH 2/3] gpio_msm: remove support for MSM7x01

Remove support for the device that has been removed from the SOC
support.

Signed-off-by: David Brown <davidb <at> codeaurora.org>
---
 drivers/gpio/gpio-msm-v1.c |   81 +-------------------------------------------
 1 files changed, 1 insertions(+), 80 deletions(-)

diff --git a/drivers/gpio/gpio-msm-v1.c b/drivers/gpio/gpio-msm-v1.c
index 52a4d42..dcd05be 100644
--- a/drivers/gpio/gpio-msm-v1.c
+++ b/drivers/gpio/gpio-msm-v1.c
 <at>  <at>  -40,73 +40,6  <at>  <at> 
 #define MSM_GPIO2_SHADOW_REG(off) (MSM_GPIO2_BASE + 0xC00 + (off))

 /*
- * MSM7X00 registers
- */
-/* output value */
-#define MSM7X00_GPIO_OUT_0	MSM_GPIO1_SHADOW_REG(0x00)  /* gpio  15-0  */
-#define MSM7X00_GPIO_OUT_1	MSM_GPIO2_SHADOW_REG(0x00)  /* gpio  42-16 */
-#define MSM7X00_GPIO_OUT_2	MSM_GPIO1_SHADOW_REG(0x04)  /* gpio  67-43 */
-#define MSM7X00_GPIO_OUT_3	MSM_GPIO1_SHADOW_REG(0x08)  /* gpio  94-68 */
-#define MSM7X00_GPIO_OUT_4	MSM_GPIO1_SHADOW_REG(0x0C)  /* gpio 106-95 */
-#define MSM7X00_GPIO_OUT_5	MSM_GPIO1_SHADOW_REG(0x50)  /* gpio 107-121 */
-
-/* same pin map as above, output enable */
-#define MSM7X00_GPIO_OE_0	MSM_GPIO1_SHADOW_REG(0x10)
-#define MSM7X00_GPIO_OE_1	MSM_GPIO2_SHADOW_REG(0x08)
-#define MSM7X00_GPIO_OE_2	MSM_GPIO1_SHADOW_REG(0x14)
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brown | 1 Dec 2011 01:29
Gravatar

[PATCH 3/3] ARM: msm: Remove cpu_is test for msm7201 soc

Now that the last bits of this target are gone, the CPU test is no
longer useful.

Signed-off-by: David Brown <davidb <at> codeaurora.org>
---
 arch/arm/mach-msm/include/mach/cpu.h |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-msm/include/mach/cpu.h b/arch/arm/mach-msm/include/mach/cpu.h
index a9481b0..e5e7fb5 100644
--- a/arch/arm/mach-msm/include/mach/cpu.h
+++ b/arch/arm/mach-msm/include/mach/cpu.h
 <at>  <at>  -20,17 +20,11  <at>  <at> 

 /* TODO: For now, only one CPU can be compiled at a time. */

-#define cpu_is_msm7x01()	0
 #define cpu_is_msm7x30()	0
 #define cpu_is_qsd8x50()	0
 #define cpu_is_msm8x60()	0
 #define cpu_is_msm8960()	0

-#ifdef CONFIG_ARCH_MSM7X00A
-# undef cpu_is_msm7x01
-# define cpu_is_msm7x01()	1
-#endif
-
 #ifdef CONFIG_ARCH_MSM7X30
 # undef cpu_is_msm7x30
 # define cpu_is_msm7x30()	1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Kara | 1 Dec 2011 01:34
Picon

Re: [dm-devel] [PATCH] deadlock with suspend and quotas

On Wed 30-11-11 11:34:23, Mikulas Patocka wrote:
> On Wed, 30 Nov 2011, Alasdair G Kergon wrote:
> > On Tue, Nov 29, 2011 at 11:19:01AM +0100, Jan Kara wrote:
> > > On Mon 28-11-11 18:32:18, Mikulas Patocka wrote:
> > > > - skipping sync on frozen filesystem violates sync semantics. 
> > > > Applications, such as databases, assume that when sync finishes, data were 
> > > > written to stable storage. If we skip sync when the filesystem is frozen, 
> > > > we can cause data corruption in these applications (if the system crashes 
> > > > after we skipped a sync).
> > 
> > >   Here I don't agree. Filesystem must guarantee there are no dirty data on
> > > a frozen filesystem. Ext4 and XFS do this, ext3 would need proper
> > > page_mkwrite() implementation for this but that's the problem of ext3, not
> > > freezing code in general. If there are no dirty data, sync code (and also
> > > flusher thread) is free to return without doing anything.
> >  
> > Consider, during a 'create a snapshot' operation:
> >    I/O flow:  application -> filesystem -> LV -> disk
> > 
> > dm lockfs is issued by LVM.
> >   When this returns, the filesystem should be locked i.e. not issue any
> >   further I/O to the LV.  (But if it did happen to issue I/O, it
> >   wouldn't be a problem, as it would just get queued by dm and have no
> >   impact on the snapshot creation operation.)
> > 
> > The application is still running and might still be issuing writes to
> > the filesystem and might itself issue 'sync'.  But a 'sync' would only
> > be meaningful for already-completed writes and the lockfs process should
> > have already seen that they have hit disk.  So a sync issued while a
> > device is locked can always be skipped.  Have I missed something in this
(Continue reading)

Permalink | Reply | 0 comments |

Gmane