Andi Kleen a écrit :
Eric Dumazet <[email protected]> writes:
1) Reduces the size of (struct fdtable) to exactly 64 bytes on 32bits
platforms, lowering kmalloc() allocated space by 50%.
It should be probably a kmem_cache_alloc() instead of a kmalloc
in the first place anyways. This would reduce fragmentation.
Well in theory yes, if you really expect thousand of tasks running...
But for most machines, number of concurrent tasks is < 200, and using a
special cache for this is not a win.
+ * read mostly part
+ */
atomic_t count;
struct fdtable *fdt;
struct fdtable fdtab;
- fd_set close_on_exec_init;
- fd_set open_fds_init;
+ /*
+ * written part on a separate cache line in SMP
+ */
+ spinlock_t file_lock ____cacheline_aligned_in_smp;
+ int next_fd;
+ embedded_fd_set close_on_exec_init;
+ embedded_fd_set open_fds_init;
You didn't describe that change, but unless it's clear the separate cache lines
are a win I would not do it and save memory again. Was this split based on
actual measurements or more theoretical considerations?
As it is a refinement on a previous patch (that was integrated in 2.6.15) that
put spin_lock after the array[] (so cleary using a separate cache line), I
omited to describe it.
Yes, this part is really important because some multi-threaded benchmarks get
a nice speedup with this separation in two parts.
Threads that are doing read()/write() (reading the first part of files_struct)
are not slowed by others that do open()/close() syscalls (writing the second
part), no false sharing (and no locking thanks to RCU of course).
Big Apache 2.0 servers, database servers directly benefit from this.
Note that process that tend to create/destroy a lot of threads per second are
writing into 'count' field and might dirty the 'read mostly' part, but we can
expect that well writen high performance programs wont do this.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
