Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 10月, 2006 3 次提交
  3. 12 10月, 2006 1 次提交
  5. 04 10月, 2006 1 次提交
  7. 03 10月, 2006 5 次提交
  9. 02 10月, 2006 6 次提交
  11. 28 9月, 2006 3 次提交
    • T
      [GFS2] inode-diet: Eliminate i_blksize from the inode structure · 825f9075
      由 Theodore Ts'o 提交于 
      This eliminates the i_blksize field from struct inode.  Filesystems that want
to provide a per-inode st_blksize can do so by providing their own getattr
routine instead of using the generic_fillattr() function.

Note that some filesystems were providing pretty much random (and incorrect)
values for i_blksize.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
      825f9075
    • T
      [GFS2] inode_diet: Replace inode.u.generic_ip with inode.i_private (gfs) · bba9dfd8
      由 Theodore Ts'o 提交于 
      The following patches reduce the size of the VFS inode structure by 28 bytes
on a UP x86.  (It would be more on an x86_64 system).  This is a 10% reduction
in the inode size on a UP kernel that is configured in a production mode
(i.e., with no spinlock or other debugging functions enabled; if you want to
save memory taken up by in-core inodes, the first thing you should do is
disable the debugging options; they are responsible for a huge amount of bloat
in the VFS inode structure).

This patch:

The filesystem or device-specific pointer in the inode is inside a union,
which is pretty pointless given that all 30+ users of this field have been
using the void pointer.  Get rid of the union and rename it to i_private, with
a comment to explain who is allowed to use the void pointer.  This is just a
cleanup, but it allows us to reuse the union 'u' for something something where
the union will actually be used.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
      bba9dfd8
    • S
      [GFS2] Fix bug in Makefiles for lock modules · 7e18c02b
      由 Steven Whitehouse 提交于 
      The Makefile had the wrong CONFIG_ variable in it so that in
case GFS2 was y and the lock modules were m, they were not
getting built properly.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      7e18c02b
  13. 25 9月, 2006 1 次提交
  15. 22 9月, 2006 1 次提交
    • S
      [GFS2] Tidy up meta_io code · 7276b3b0
      由 Steven Whitehouse 提交于 
      Fix a bug in the directory reading code, where we might have dereferenced
a NULL pointer in case of OOM. Updated the directory code to use the new
& improved version of gfs2_meta_ra() which now returns the first block
that was being read. Previously it was releasing it requiring following
code to grab the block again at each point it was called.

Also turned off readahead on directory lookups since we are reading a
hash table, and therefore reading the entries in order is very
unlikely. Readahead is still used for all other calls to the
directory reading function (e.g. when growing the hash table).

Removed the DIO_START constant. Everywhere this was used, it was
used to unconditionally start i/o aside from a couple of places, so
I've removed it and made the couple of exceptions to this rule into
separate functions.

Also hunted through the other DIO flags and removed them as arguments
from functions which were always called with the same combination of
arguments.

Updated gfs2_meta_indirect_buffer to be a bit more efficient and
hopefully also be a bit easier to read.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      7276b3b0
  17. 21 9月, 2006 1 次提交
  19. 20 9月, 2006 1 次提交
  21. 19 9月, 2006 6 次提交
  23. 18 9月, 2006 1 次提交
  25. 15 9月, 2006 1 次提交
  27. 13 9月, 2006 2 次提交
  29. 12 9月, 2006 2 次提交
    • S
      [GFS2] Use hlist for glock hash chains · b6397893
      由 Steven Whitehouse 提交于 
      This results in smaller list heads, so that we can have more chains
in the same amount of memory (twice as many). I've multiplied the
size of the table by four though - this is because we are saving
memory by not having one lock per chain any more. So we land up
using about the same amount of memory for the hash table as we
did before I started these changes, the difference being that we
now have four times as many hash chains.

The reason that I say "about the same amount of memory" is that the
actual amount now depends upon the NR_CPUS and some of the config
variables, so that its not exact and in some cases we do use more
memory. Eventually we might want to scale the hash table size
according to the size of physical ram as measured on module load.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      b6397893
    • S
      [GFS2] Rewrite of examine_bucket() · 24264434
      由 Steven Whitehouse 提交于 
      The existing implementation of this function in glock.c was not
very efficient as it relied upon keeping a cursor element upon the
hash chain in question and moving it along. This new version improves
upon this by using the current element as a cursor. This is possible
since we only look at the "next" element in the list after we've
taken the read_lock() subsequent to calling the examiner function.
Obviously we have to eventually drop the ref count that we are then
left with and we cannot do that while holding the read_lock, so we
do that next time we drop the lock. That means either just before
we examine another glock, or when the loop has terminated.

The new implementation has several advantages: it uses only a
read_lock() rather than a write_lock(), so it can run simnultaneously
with other code, it doesn't need a "plug" element, so that it removes
a test not only from this list iterator, but from all the other glock
list iterators too. So it makes things faster and smaller.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      24264434
  31. 10 9月, 2006 4 次提交
  33. 09 9月, 2006 1 次提交
    • S
      [GFS2] Move rwlocks in glock.c into their own array · 37b2fa6a
      由 Steven Whitehouse 提交于 
      This splits the rwlocks guarding the hash chains of the glock hash
table into their own array. This will reduce memory usage in some
cases due to better alignment, although the real reason for doing it
is to allow the two tables to be different sizes in future (i.e.
the locks will be sized proportionally with the max number of CPUs
and the hash chains sized proportinally with the size of physical memory)

In order to allow this, the gl_bucket member of struct gfs2_glock has
now become gl_hash, so we record the hash rather than a pointer to the
bucket itself.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      37b2fa6a