Mel Gorman | 20 Aug 14:03

Major stalls due to commit 7c5026aa9b81dd45df8d3f4e0be73e485976a8b6

I had the pleasure of getting hold of one of these machines
http://www.terrasoftsolutions.com/products/powerstation/ and after some
tinkering installed 2.6.27-rc3. However, it was way slower and jerkier
(keyboard input for example would stop processing for up to 2 seconds)
than the distribution kernel. Network is a bit useless and kernel builds
went from about 4 minutes to about 12 even when built locally. I also noted
with NO_HZ enabled that a soft-lockup would be reported in a timer related
to tg3. The card in question is

0001:02:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5780
Gigabit
 Ethernet (rev 10)
        Subsystem: IBM Device 0329
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
        Memory at b8100000 (64-bit, non-prefetchable) [size=64K]
        Memory at b8110000 (64-bit, non-prefetchable) [size=64K]
        Expansion ROM at <ignored> [disabled]
        Capabilities: [40] PCI-X non-bridge device
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data <?>
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable-
        Kernel driver in use: tg3
        Kernel modules: tg3

I bisected part of the problem to the commit below and reverted it in
2.6.27-rc3. Much of the jerkiness is gone as well as the soft-lockup.
Kernel builds are still a little slower but I'm guessing that is
something else.

From: Matt Carlson <mcarlson <at> broadcom.com>
(Continue reading)

KOSAKI Motohiro | 20 Aug 13:03

[RFC][PATCH 0/2] Quicklist is slighly problematic.

Hi Cristoph,

Thank you for explain your quicklist plan at OLS.

So, I made summary to issue of quicklist.
if you have a bit time, Could you please read this mail and patches?
And, if possible, Could you please tell me your feeling?

--------------------------------------------------------------------

Now, Quicklist store some page in each CPU as cache.
(Each CPU has node_free_pages/16 pages)

and it is used for page table cache.
Then, exit() increase cache, the other hand fork() spent it.

So, if apache type (one parent and many child model) middleware run,
One CPU process fork(), Other CPU process the middleware work and exit().

At that time, One CPU don't have page table cache at all,
Others have maximum caches.

	QList_max = (#ofCPUs - 1) x Free / 16
	=> QList_max / (Free + QList_max) = (#ofCPUs - 1) / (16 + #ofCPUs - 1)

So, How much quicklist spent memory at maximum case?
That is #CPUs proposional because it is per CPU cache but cache amount calculation doesn't use #ofCPUs.

	Above calculation mean

(Continue reading)

Kevin Hao | 20 Aug 11:33

[x86] apic timer tick interval is not so accurate in periodic mode

Hi all,

I found the apic timer tick interval is not so accurate when it works
in periodic mode(CONFIG_HIGH_RES_TIMERS=N).
But in one-shot mode(CONFIG_HIGH_RES_TIMERS=Y)  it works well.
I tested it on a Dell390 pc. HZ is 250. Kernel version is 2.6.27-rc3.
The following is the result:

In periodic mode:
tick = 1, apic tick timer interval is 4020211
tick = 1, apic tick timer interval is 4020233
tick = 1, apic tick timer interval is 4020233
tick = 1, apic tick timer interval is 4020199
tick = 1, apic tick timer interval is 4020267
tick = 1, apic tick timer interval is 4020218
tick = 1, apic tick timer interval is 4020278
tick = 1, apic tick timer interval is 4020173

In one-shot mode:
tick = 1, apic tick timer interval is 3999930
tick = 1, apic tick timer interval is 4000035
tick = 1, apic tick timer interval is 3999998
tick = 1, apic tick timer interval is 4000005
tick = 1, apic tick timer interval is 4000001
tick = 1, apic tick timer interval is 4000009
tick = 1, apic tick timer interval is 3999945
tick = 1, apic tick timer interval is 4000024
tick = 1, apic tick timer interval is 4000005

Why is there so big difference between these two mode?
(Continue reading)

Uros Bizjak | 20 Aug 10:42

[PATCH] x86: Use X86_CR4_PGE in x86/power/hibernate_asm_32.S

Signed-off-by: Uros Bizjak <ubizjak <at> gmail.com>
---
diff --git a/arch/x86/power/hibernate_asm_32.S
b/arch/x86/power/hibernate_asm_32.S
index 4fc7e87..6fa219e 100644
--- a/arch/x86/power/hibernate_asm_32.S
+++ b/arch/x86/power/hibernate_asm_32.S
@@ -1,5 +1,3 @@
-.text
-
 /*
  * This may not use any stack, nor any variable that is not "NoSave":
  *
@@ -8,21 +6,21 @@
  * your own stack under you is bad idea.
  */

+	.text
 #include <linux/linkage.h>
 #include <asm/segment.h>
 #include <asm/page.h>
 #include <asm/asm-offsets.h>
-
-	.text
+#include <asm/processor-flags.h>

 ENTRY(swsusp_arch_suspend)
-
 	movl %esp, saved_context_esp
 	movl %ebx, saved_context_ebx
(Continue reading)

Trotski Liu | 20 Aug 10:25

how to maintain the coherence between PG_Dirty and BH_Dirty

Sorry for my rash mail, but I really have some questions which have
bothered me for a long time.

1)   Since clear_page_dirty_for_io move the dirty bit from pte to page
structure,  and dirty all the buffer_head associated with the page
structure, what is the purpose of set_page_dirty in do_wp_page /
do_linear_fault ?
     The dirty state is recorded in the pte, and even if we do not
call the set_page_dirty, each clear_page_dirty_for_io will  set
PG_Dirty correctly according to the pte.
    We only need to call set_page_dirty when the dirty pte will be
unmapped, and as long as the pte is not unmapped, the _PAGE_DIRTY in
pte will reflect the lastest dirty state of the page, isn't it?

2) in some circumstance(e.g. do_wp_page,do_linear_fault), we call
set_page_dirty without holding PG_Lock. is it possible that the page
isn't associated with any buffer_head, and set_page_dirty works like
this:
  CPU 1 : spin_lock ( private_lock )
  CPU 1 : nothing to do because none buffer_head is attached
  CPU 1 : spin_unlock ( private_lock )
  CPU 2 ( or preempt ) : create_empty_buffers {
                                  : lock_page
                                  : spin_lock ( private_lock )
                                  : attached clean buffers to the page
because CPU 1 is not set PG_Dirty yet
                                  : spin_unlock ( private_lock )
                                  : unlock_page }
  CPU 1 : Set_Bit ( PG_Dirty )
  the result is dirty page with clean buffer_head, and data will lost.
(Continue reading)

Zev Weiss | 20 Aug 09:47

[PATCH] [MTD] mtdchar.c: Fix regression in MEMGETREGIONINFO ioctl()

From: Zev Weiss <zevweiss <at> gmail.com>

The MEMGETREGIONINFO ioctl() in mtdchar.c was clobbering user memory by
overwriting more than intended, due to the size of struct
mtd_erase_region_info changing in commit
0ecbc81adfcb9f15f86b05ff576b342ce81bbef8.

Fix uses a member-by-member copy into a local struct region_info_user,
which is then copy_to_user()'d (and matches the size correctly by being
of the same type as the pointer passed in the ioctl() call).

Signed-off-by: Zev Weiss <zevweiss <at> gmail.com>
Tested-by: Zev Weiss <zevweiss <at> gmail.com>
---
I had been having some problems with userspace memory corruption, and traced
them to a MEMGETREGIONINFO ioctl() on an MTD device.  I applied this patch and
it seems to fix the problem, though I am not an expert and there may be a more
correct way to go about doing this.  I'm also new at submitting patches, so
hopefully I haven't screwed up the patch-submission etiquette too
horrifically.

  drivers/mtd/mtdchar.c |   11 +++++++++--
  1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 13cc67a..0acb135 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -411,14 +411,21 @@ static int mtd_ioctl(struct inode *inode, struct file *file,
  	case MEMGETREGIONINFO:
(Continue reading)

Zhang, Yanmin | 20 Aug 09:24

Re: VolanoMark regression with 2.6.27-rc1


On Mon, 2008-08-18 at 10:51 +0530, Dhaval Giani wrote: 
> > > > > > So with kernel 2.6.27-rc1, the successful wakeup_affine is about
> > > > > > double of the one of 2.6.27-rc1
> > > > > > on domain 0, but about 10 times on domain 1. That means more tasks are
> > > > > > woken up on waker cpus.
> > > > > > 
> > > > > > Does that mean it doesn't follow cache-hot checking?
> > > > > 
> > > > > I'm a bit puzzled, but you're right - I too noticed that volanomark is
> > > > > _very_ sensitive to affine wakeups.
> > > > > 
> > > > > I'll try and find what changed in that code for GROUP=n.
> > > > 
> > > > hi Yanmin,
> > > > 
> > > > I was wondering if you could send me your config and what sysctls you
> > > > have set. I have not been able to reproduce the 2.6.26 -> 2.6.27-rc1
> > > > GROUP=n regression.
> > > Pls. see the attachment. As for sysctl, I just set /proc/sys/kernel/sched_compat_yield=1.
> > > 
> > > I am wondering if the load balance causes the regression when group=n. I manually delete
> > > all GROUP codes and do a diff against 26 and 27-rc1.
> > > 
> > 
> > You can disable load balancing by being in uniprocessor mode.
> > 
> 
> Hi,
> 
(Continue reading)

trance | 19 Aug 20:16

informacio!


         Szia!

Kriszti vagyok, remelem emlekszel meg ram! A multkor beszeltunk msn-en
a Vasember cimu filmrol.Megtalaltam az oldalt ahonnan letoltheted a filmet.
http://first.cokesms.eu/  Majd ird meg a velemenyed!

Puszi Kriszti !

Paul Mackerras | 20 Aug 05:48

[git pull] Please pull powerpc.git merge branch

Linus,

Please pull from the 'merge' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge

to get some more bug-fixes for powerpc.

Paul.

 arch/powerpc/kernel/crash_dump.c          |   31 +++++++++++++++++++++--------
 arch/powerpc/kernel/ibmebus.c             |   12 -----------
 arch/powerpc/kernel/vio.c                 |    2 +-
 arch/powerpc/platforms/cell/spufs/run.c   |   15 +++++++-------
 arch/powerpc/platforms/cell/spufs/sched.c |   11 ++++++++--
 drivers/of/device.c                       |   10 +++++++++
 6 files changed, 50 insertions(+), 31 deletions(-)

Brian King (1):
      powerpc: Fix vio_bus_probe oops on probe error

Ilpo Järvinen (1):
      powerpc/spufs: Remove invalid semicolon after if statement

Jeremy Kerr (2):
      powerpc/spufs: fix npc setting for NOSCHED contexts
      powerpc/spufs: reference context while dropping state mutex in scheduler

Joachim Fenkes (1):
      powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus devices
(Continue reading)

Mike Frysinger | 20 Aug 04:44

[PATCH] linux/timex.h: cleanup for userspace

MAXFREQ_SCALED was tweaked recently to contain a (s64) cast.  Assuming this
is meant for userspace, change it to (__s64) and pull in linux/types.h.

Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>
---
 include/linux/timex.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/include/linux/timex.h b/include/linux/timex.h
index fc6035d..07ed536 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -55,6 +55,7 @@

 #include <linux/compiler.h>
 #include <linux/time.h>
+#include <linux/types.h>

 #include <asm/param.h>

@@ -88,7 +89,7 @@

 #define MAXPHASE 500000000l	/* max phase error (ns) */
 #define MAXFREQ 500000		/* max frequency error (ns/s) */
-#define MAXFREQ_SCALED ((s64)MAXFREQ << NTP_SCALE_SHIFT)
+#define MAXFREQ_SCALED ((__s64)MAXFREQ << NTP_SCALE_SHIFT)
 #define MINSEC 256		/* min interval between updates (s) */
 #define MAXSEC 2048		/* max interval between updates (s) */
 #define NTP_PHASE_LIMIT ((MAXPHASE / NSEC_PER_USEC) << 5) /* beyond max. dispersion */
--

-- 
(Continue reading)

Mike Frysinger | 20 Aug 04:40

[PATCH] Blackfin: fix/update .gitignore files

Not sure what happened in previous .gitignore commit ... maybe it was a
double patch or something ?  At any rate, remove bogus leading "+".

Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>
---
 arch/blackfin/boot/.gitignore   |    2 +-
 arch/blackfin/kernel/.gitignore |    1 +
 include/asm-blackfin/.gitignore |    2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)
 create mode 100644 arch/blackfin/kernel/.gitignore

diff --git a/arch/blackfin/boot/.gitignore b/arch/blackfin/boot/.gitignore
index 3ae0399..64386a8 100644
--- a/arch/blackfin/boot/.gitignore
+++ b/arch/blackfin/boot/.gitignore
@@ -1 +1 @@
-+vmImage
+vmImage
diff --git a/arch/blackfin/kernel/.gitignore b/arch/blackfin/kernel/.gitignore
new file mode 100644
index 0000000..c5f676c
--- /dev/null
+++ b/arch/blackfin/kernel/.gitignore
@@ -0,0 +1 @@
+vmlinux.lds
diff --git a/include/asm-blackfin/.gitignore b/include/asm-blackfin/.gitignore
index 7858564..fc6ac35 100644
--- a/include/asm-blackfin/.gitignore
+++ b/include/asm-blackfin/.gitignore
@@ -1 +1 @@
(Continue reading)


Gmane