From: Dave Hansen <hansendc@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, hch@infradead.org
Subject: Re: [PATCH 12/22] elevate write count files are open()ed
Date: Tue, 13 Feb 2007 16:17:37 -0800 [thread overview]
Message-ID: <1171412257.30997.21.camel@localhost.localdomain> (raw)
In-Reply-To: <20070213095817.d2a8a380.akpm@linux-foundation.org>
On Tue, 2007-02-13 at 09:58 -0800, Andrew Morton wrote:
> > On Tue, 13 Feb 2007 08:58:16 -0800 Dave Hansen <hansendc@us.ibm.com> wrote:
> > > yipes. A new mount-wide spin_lock/unlock for each for-writing open() and close().
> > > Can we have a microbenchmark on this please?
> >
> > Yeah, I'll schedule some dbench time on a NUMA machine.
>
> dbench doesn't do open() a lot. To assess the worst-case we'd need one
> process per cpu camping in an open/close loop.
This is definitely a worst-case scenario. A 32-way x86_64 NUMA machine
(with a pretty crappy interconnect) with a process-per-cpu all beating
on the same filesystem.
no patch:
real: 30.111s
user: 0.031s
sys: 2.685s
r/o bind mount patch:
real: 48.359s
user: 0.146s
sys: 47.984s
It definitely makes a huge difference in system time, although not a
fatal one. Christoph, what do you think? Back to caching the
superblock flag in the mount?
#!/bin/sh
# go.sh
name=`uname -r`
grep -q /mnt/ram /proc/mounts || mount -t ramfs ram /mnt/ram;
make openbench;
nr_cpus=`cat /proc/cpuinfo | grep -c ^processor`
for ((run=0;run<5;run++)); do
dir=$name.run.$run;
mkdir -p $dir;
for ((i=0;i<nr_cpus;i++)); do
{ time taskset -c $i ./openbench $((1<<16)) & } \
> $dir/openbench.time.$i 2>&1
done;
wait
echo run $run done
done
// openbench.c
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
void main(int argc, char **argv)
{
pid_t pid = getpid();
char buf[100];
int ret;
int fd;
int i;
int loops = atoi(argv[1]);
sprintf(&buf[0], "/mnt/ram/openbench.%d", pid);
for (i=0; i< loops; i++) {
fd = open(&buf[0], O_WRONLY|O_CREAT);
if (fd < 0) {
perror("open error");
exit(fd);
}
write(fd, "foo");
close(fd);
}
ret = unlink(&buf[0]);
if (ret)
perror("unlink error");
}
-- Dave
next prev parent reply other threads:[~2007-02-14 0:17 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-09 22:53 [PATCH 01/22] filesystem helpers for custom 'struct file's Dave Hansen
2007-02-09 22:53 ` [PATCH 02/22] r/o bind mounts: add vfsmount writer counts Dave Hansen
2007-02-09 23:41 ` Eric Dumazet
2007-02-10 0:10 ` Dave Hansen
2007-02-09 22:53 ` [PATCH 04/22] elevate writer count for chown and friends Dave Hansen
2007-02-09 22:53 ` [PATCH 03/22] record when sb_writer_count elevated for inode Dave Hansen
2007-02-09 22:53 ` [PATCH 05/22] elevate mnt writers for callers of vfs_mkdir() Dave Hansen
2007-02-09 22:53 ` [PATCH 06/22] elevate write count during entire ncp_ioctl() Dave Hansen
2007-02-09 22:53 ` [PATCH 07/22] elevate write count for link and symlink calls Dave Hansen
2007-02-09 22:53 ` [PATCH 08/22] elevate mount count for extended attributes Dave Hansen
2007-02-09 22:53 ` [PATCH 09/22] mount_is_safe(): add comment Dave Hansen
2007-02-09 22:53 ` [PATCH 10/22] unix_find_other() elevate write count for touch_atime() Dave Hansen
2007-02-09 22:53 ` [PATCH 12/22] elevate write count files are open()ed Dave Hansen
2007-02-13 5:11 ` Andrew Morton
2007-02-13 16:58 ` Dave Hansen
2007-02-13 17:58 ` Andrew Morton
2007-02-14 0:17 ` Dave Hansen [this message]
2007-02-09 22:53 ` [PATCH 11/22] elevate write count over calls to vfs_rename() Dave Hansen
2007-02-09 22:53 ` [PATCH 13/22] elevate writer count for do_sys_truncate() Dave Hansen
2007-02-09 22:53 ` [PATCH 14/22] elevate write count for do_utimes() Dave Hansen
2007-02-09 22:53 ` [PATCH 16/22] sys_mknodat(): elevate write count for vfs_mknod/create() Dave Hansen
2007-02-09 22:53 ` [PATCH 15/22] elevate write count for do_sys_utime() and touch_atime() Dave Hansen
2007-02-09 22:53 ` [PATCH 17/22] elevate mnt writers for vfs_unlink() callers Dave Hansen
2007-02-09 22:53 ` [PATCH 18/22] do_rmdir(): elevate write count Dave Hansen
2007-02-09 22:53 ` [PATCH 19/22] elevate writer count for custom struct_file Dave Hansen
2007-02-09 22:53 ` [PATCH 20/22] [PATCH] gfs: check nlink count Dave Hansen
2007-02-09 22:53 ` [PATCH 21/22] honor r/w changes at do_remount() time Dave Hansen
2007-02-09 23:22 ` Andrew Morton
2007-02-10 0:00 ` Dave Hansen
2007-02-10 0:29 ` Anton Altaparmakov
2007-02-10 9:54 ` Jan Engelhardt
2007-02-09 22:53 ` [PATCH 22/22] kill open files traverse on remount ro Dave Hansen
2007-02-09 23:18 ` [PATCH 01/22] filesystem helpers for custom 'struct file's Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1171412257.30997.21.camel@localhost.localdomain \
--to=hansendc@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox