Skip to content

K
Kernel

openeuler / Kernel
12 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 18 4月, 2017 1 次提交
  3. 14 2月, 2017 1 次提交
    • N
      btrfs: Make btrfs_ino take a struct btrfs_inode · 4a0cc7ca
      由 Nikolay Borisov 提交于 
      Currently btrfs_ino takes a struct inode and this causes a lot of
internal btrfs functions which consume this ino to take a VFS inode,
rather than btrfs' own struct btrfs_inode. In order to fix this "leak"
of VFS structs into the internals of btrfs first it's necessary to
eliminate all uses of struct inode for the purpose of inode. This patch
does that by using BTRFS_I to convert an inode to btrfs_inode. With
this problem eliminated subsequent patches will start eliminating the
passing of struct inode altogether, eventually resulting in a lot cleaner
code.
Signed-off-by: NNikolay Borisov <n.borisov.lkml@gmail.com>
[ fix btrfs_get_extent tracepoint prototype ]
Signed-off-by: NDavid Sterba <dsterba@suse.com>
      4a0cc7ca
  5. 09 1月, 2017 4 次提交
  7. 06 12月, 2016 2 次提交
  9. 30 11月, 2016 1 次提交
  11. 26 7月, 2016 1 次提交
  13. 08 7月, 2016 3 次提交
  15. 04 4月, 2016 1 次提交
  17. 16 3月, 2016 1 次提交
    • V
      mm, tracing: unify mm flags handling in tracepoints and printk · 420adbe9
      由 Vlastimil Babka 提交于 
      In tracepoints, it's possible to print gfp flags in a human-friendly
format through a macro show_gfp_flags(), which defines a translation
array and passes is to __print_flags().  Since the following patch will
introduce support for gfp flags printing in printk(), it would be nice
to reuse the array.  This is not straightforward, since __print_flags()
can't simply reference an array defined in a .c file such as mm/debug.c
- it has to be a macro to allow the macro magic to communicate the
format to userspace tools such as trace-cmd.

The solution is to create a macro __def_gfpflag_names which is used both
in show_gfp_flags(), and to define the gfpflag_names[] array in
mm/debug.c.

On the other hand, mm/debug.c also defines translation tables for page
flags and vma flags, and desire was expressed (but not implemented in
this series) to use these also from tracepoints.  Thus, this patch also
renames the events/gfpflags.h file to events/mmflags.h and moves the
table definitions there, using the same macro approach as for gfpflags.
This allows translating all three kinds of mm-specific flags both in
tracepoints and printk.
Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
Reviewed-by: NMichal Hocko <mhocko@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      420adbe9
  19. 18 12月, 2015 1 次提交
    • O
      Btrfs: introduce the free space B-tree on-disk format · 208acb8c
      由 Omar Sandoval 提交于 
      The on-disk format for the free space tree is straightforward. Each
block group is represented in the free space tree by a free space info
item that stores accounting information: whether the free space for this
block group is stored as bitmaps or extents and how many extents of free
space exist for this block group (regardless of which format is being
used in the tree). Extents are (start, FREE_SPACE_EXTENT, length) keys
with no corresponding item, and bitmaps instead have the
FREE_SPACE_BITMAP type and have a bitmap item attached, which is just an
array of bytes.
Reviewed-by: NJosef Bacik <jbacik@fb.com>
Signed-off-by: NOmar Sandoval <osandov@fb.com>
Signed-off-by: NChris Mason <clm@fb.com>
      208acb8c
  21. 22 10月, 2015 1 次提交
  23. 11 6月, 2015 1 次提交
  25. 16 4月, 2015 1 次提交
  27. 25 3月, 2015 1 次提交
  29. 18 9月, 2014 5 次提交
  31. 21 3月, 2014 1 次提交
  33. 11 3月, 2014 1 次提交
  35. 29 1月, 2014 2 次提交
  37. 21 11月, 2013 1 次提交
    • S
      btrfs: Use trace condition for get_extent tracepoint · 4cd8587c
      由 Steven Rostedt 提交于 
      Doing an if statement to test some condition to know if we should
trigger a tracepoint is pointless when tracing is disabled. This just
adds overhead and wastes a branch prediction. This is why the
TRACE_EVENT_CONDITION() was created. It places the check inside the jump
label so that the branch does not happen unless tracing is enabled.

That is, instead of doing:

	if (em)
		trace_btrfs_get_extent(root, em);

Which is basically this:

	if (em)
		if (static_key(trace_btrfs_get_extent)) {

Using a TRACE_EVENT_CONDITION() we can just do:

	trace_btrfs_get_extent(root, em);

And the condition trace event will do:

	if (static_key(trace_btrfs_get_extent)) {
		if (em) {
			...

The static key is a non conditional jump (or nop) that is faster than
having to check if em is NULL or not.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      4cd8587c
  39. 21 9月, 2013 1 次提交
  41. 01 9月, 2013 1 次提交
  43. 14 6月, 2013 1 次提交
  45. 17 12月, 2012 1 次提交
  47. 02 10月, 2012 1 次提交
  49. 22 3月, 2012 1 次提交
  51. 17 1月, 2012 2 次提交
  53. 08 6月, 2011 1 次提交
  55. 26 5月, 2011 1 次提交