Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 19 9月, 2006 3 次提交
    • S
      [GFS2] Tweek unlock test in readpage() · 07903c02
      由 Steven Whitehouse 提交于 
      This make the unlock test a bit simpler.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      07903c02
    • R
      [GFS2] Fix for mmap() bug in readpage · dc41aeed
      由 Russell Cattelan 提交于 
      Fix for Red Hat bz 205307. Don't need to lock in readpage if
the higher level code has already grabbed the lock.
Signed-off-by: NRussell Cattelan <cattelan@redhat.com>
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      dc41aeed
    • S
      [GFS2] Map multiple blocks at once where possible · 7a6bbacb
      由 Steven Whitehouse 提交于 
      This is a tidy up of the GFS2 bmap code. The main change is that the
bh is passed to gfs2_block_map allowing the flags to be set directly
rather than having to repeat that code several times in ops_address.c.

At the same time, the extent mapping code from gfs2_extent_map has
been moved into gfs2_block_map. This allows all calls to gfs2_block_map
to map extents in the case that no allocation is taking place. As a
result reads and non-allocating writes should be faster. A quick test
with postmark appears to support this.

There is a limit on the number of blocks mapped in a single bmap
call in that it will only ever map blocks which are pointed to
from a single pointer block. So in other words, it will never try
to do additional i/o in order to satisfy read-ahead. The maximum
number of blocks is thus somewhat less than 512 (the GFS2 4k block
size minus the header divided by sizeof(u64)). I've further limited
the mapping of "normal" blocks to 32 blocks (to avoid extra work)
since readpages() will currently read a maximum of 32 blocks ahead (128k).

Some further work will probably be needed to set a suitable value
for DIO as well, but for now thats left at the maximum 512 (see
ops_address.c:gfs2_get_block_direct).

There is probably a lot more that can be done to improve bmap for GFS2,
but this is a good first step.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      7a6bbacb
  3. 18 9月, 2006 1 次提交
  5. 15 9月, 2006 1 次提交
  7. 13 9月, 2006 2 次提交
  9. 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
  11. 10 9月, 2006 4 次提交
  13. 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
  15. 08 9月, 2006 7 次提交
  17. 07 9月, 2006 3 次提交
  19. 06 9月, 2006 5 次提交
  21. 05 9月, 2006 11 次提交