Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 4月, 2009 1 次提交
  3. 11 4月, 2009 1 次提交
  5. 07 4月, 2009 3 次提交
  7. 03 4月, 2009 4 次提交
  9. 01 4月, 2009 2 次提交
  11. 31 3月, 2009 2 次提交
  13. 30 3月, 2009 4 次提交
  15. 29 3月, 2009 1 次提交
  17. 26 3月, 2009 1 次提交
    • L
      init,cpuset: fix initialize order · 759ee091
      由 Lai Jiangshan 提交于 
      Impact: cpuset_wq should be initialized after init_workqueues()

When I read /debugfs/tracing/trace_stat/workqueues,
I got this:

 # CPU  INSERTED  EXECUTED   NAME
 # |      |         |          |

   0      0          0       cpuset
   0    285        285       events/0
   0      2          2       work_on_cpu/0
   0   1115       1115       khelper
   0    325        325       kblockd/0
   0      0          0       kacpid
   0      0          0       kacpi_notify
   0      0          0       ata/0
   0      0          0       ata_aux
   0      0          0       ksuspend_usbd
   0      0          0       aio/0
   0      0          0       nfsiod
   0      0          0       kpsmoused
   0      0          0       kstriped
   0      0          0       kondemand/0
   0      1          1       hid_compat
   0      0          0       rpciod/0

   1     64         64       events/1
   1      2          2       work_on_cpu/1
   1      5          5       kblockd/1
   1      0          0       ata/1
   1      0          0       aio/1
   1      0          0       kondemand/1
   1      0          0       rpciod/1

I found "cpuset" is at the earliest.

I found a create_singlethread_workqueue() is earlier than
init_workqueues():

kernel_init()
->cpuset_init_smp()
  ->create_singlethread_workqueue()
->do_basic_setup()
  ->init_workqueues()

I think it's better that create_singlethread_workqueue() is called
after workqueue subsystem has been initialized.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>
Acked-by: NSteven Rostedt <srostedt@redhat.com>
Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
Cc: Paul Menage <menage@google.com>
Cc: miaoxie <miaox@cn.fujitsu.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <49C9F416.1050707@cn.fujitsu.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      759ee091
  19. 11 3月, 2009 1 次提交
  21. 03 3月, 2009 2 次提交
  23. 26 2月, 2009 1 次提交
    • P
      rcu: Teach RCU that idle task is not quiscent state at boot · a6826048
      由 Paul E. McKenney 提交于 
      This patch fixes a bug located by Vegard Nossum with the aid of
kmemcheck, updated based on review comments from Nick Piggin,
Ingo Molnar, and Andrew Morton.  And cleans up the variable-name
and function-name language.  ;-)

The boot CPU runs in the context of its idle thread during boot-up.
During this time, idle_cpu(0) will always return nonzero, which will
fool Classic and Hierarchical RCU into deciding that a large chunk of
the boot-up sequence is a big long quiescent state.  This in turn causes
RCU to prematurely end grace periods during this time.

This patch changes the rcutree.c and rcuclassic.c rcu_check_callbacks()
function to ignore the idle task as a quiescent state until the
system has started up the scheduler in rest_init(), introducing a
new non-API function rcu_idle_now_means_idle() to inform RCU of this
transition.  RCU maintains an internal rcu_idle_cpu_truthful variable
to track this state, which is then used by rcu_check_callback() to
determine if it should believe idle_cpu().

Because this patch has the effect of disallowing RCU grace periods
during long stretches of the boot-up sequence, this patch also introduces
Josh Triplett's UP-only optimization that makes synchronize_rcu() be a
no-op if num_online_cpus() returns 1.  This allows boot-time code that
calls synchronize_rcu() to proceed normally.  Note, however, that RCU
callbacks registered by call_rcu() will likely queue up until later in
the boot sequence.  Although rcuclassic and rcutree can also use this
same optimization after boot completes, rcupreempt must restrict its
use of this optimization to the portion of the boot sequence before the
scheduler starts up, given that an rcupreempt RCU read-side critical
section may be preeempted.

In addition, this patch takes Nick Piggin's suggestion to make the
system_state global variable be __read_mostly.

Changes since v4:

o	Changes the name of the introduced function and variable to
	be less emotional.  ;-)

Changes since v3:

o	WARN_ON(nr_context_switches() > 0) to verify that RCU
	switches out of boot-time mode before the first context
	switch, as suggested by Nick Piggin.

Changes since v2:

o	Created rcu_blocking_is_gp() internal-to-RCU API that
	determines whether a call to synchronize_rcu() is itself
	a grace period.

o	The definition of rcu_blocking_is_gp() for rcuclassic and
	rcutree checks to see if but a single CPU is online.

o	The definition of rcu_blocking_is_gp() for rcupreempt
	checks to see both if but a single CPU is online and if
	the system is still in early boot.

	This allows rcupreempt to again work correctly if running
	on a single CPU after booting is complete.

o	Added check to rcupreempt's synchronize_sched() for there
	being but one online CPU.

Tested all three variants both SMP and !SMP, booted fine, passed a short
rcutorture test on both x86 and Power.
Located-by: NVegard Nossum <vegard.nossum@gmail.com>
Tested-by: NVegard Nossum <vegard.nossum@gmail.com>
Tested-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a6826048
  25. 22 2月, 2009 1 次提交
  27. 21 2月, 2009 1 次提交
    • F
      tracing/markers: make markers select tracepoints · 91f73f90
      由 Frederic Weisbecker 提交于 
      Sometimes it happens that KConfig dependencies are not handled
like in the following scenario:

- config A
   bool

- config B
   bool
   depends on A

- config C
   bool
   select B

If one selects C, then it will select B without checking its
dependency to A, if A hasn't been selected elsewhere, it will
result in a build failure.

This is what happens on the following build error:

 kernel/built-in.o: In function `marker_update_probe_range':
 (.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
 kernel/built-in.o: In function `marker_update_probe_range':
 (.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
 kernel/built-in.o: In function `marker_update_probe_range':
 (.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
 kernel/built-in.o: In function `marker_update_probes':
 marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'

CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter
depends on CONFIG_TRACEPOINTS which will not be selected.
Reported-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      91f73f90
  29. 06 2月, 2009 1 次提交
  31. 27 1月, 2009 1 次提交
  33. 16 1月, 2009 4 次提交
  35. 15 1月, 2009 2 次提交
  37. 13 1月, 2009 1 次提交
  39. 10 1月, 2009 1 次提交
    • I
      bzip2/lzma: make flush_buffer() unconditional · 736f9323
      由 Ingo Molnar 提交于 
      Impact: build fix

flush_buffer() is used unconditionally:

  init/initramfs.c:456: error: 'flush_buffer' undeclared (first use in this function)
  init/initramfs.c:456: error: (Each undeclared identifier is reported only once
  init/initramfs.c:456: error: for each function it appears in.)

So remove the decompressor #ifdefs from around it.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      736f9323
  41. 09 1月, 2009 4 次提交
  43. 08 1月, 2009 1 次提交
    • D
      NOMMU: Support XIP on initramfs · cb6ff208
      由 David Howells 提交于 
      Support XIP on files unpacked from the initramfs image on NOMMU systems.  This
simply requires the length of the file to be preset so that the ramfs fs can
attempt to garner sufficient contiguous storage to store the file (NOMMU mmap
can only map contiguous RAM).

All the other bits to do XIP on initramfs files are present:

 (1) ramfs's truncate attempts to allocate a contiguous run of pages when a
     file is truncated upwards from nothing.

 (2) ramfs sets BDI on its files to indicate direct mapping is possible, and
     that its files can be mapped for read, write and exec.

 (3) NOMMU mmap() will use the above bits to determine that it can do XIP.
     Possibly this needs better controls, because it will _always_ try and do
     XIP.

One disadvantage of this very simplistic approach is that sufficient space
will be allocated to store the whole file, and not just the bit that would be
XIP'd.  To deal with this, though, the initramfs unpacker would have to be
able to parse the file contents.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
      cb6ff208