similar to: how to know ext cache hit rate?

On Wed, Dec 25, 2013 at 09:32:50AM +0800, fsluck wrote: > how to know ext cache hit rate? Which cache are you referring to, specifically? The page cache? The inode cache? The dentry cache? What problem are you trying to solve, at a high level? - Ted

On Wed, Feb 26, 2014 at 04:01:00PM +0800, fsluck wrote: > i think it is page cache. my case is in virualization environment, > because vm's disk image is much larger than system's cache, i want > to know when many vms are running if system cache hit rate is very > low? if there is a need to seek for other way to suit > virtualization. Why not simply measure the I/O rate

i think it is page cache. my case is in virualization environment, because vm's disk image is much larger than system's cache, i want to know when many vms are running if system cache hit rate is very low? if there is a need to seek for other way to suit virtualization. system's default cache mechanism does not care about virtualization. thanks At 2013-12-26

Commit 4490001029012539937ff02778fe6180613fa949 ("virtio-net: enable multiqueue by default") blindly set the affinity instead of queues during probe which can cause a mismatch of #queues between guest and host. This patch fixes it by setting queues. Reported-by: Theodore Ts'o <tytso at mit.edu> Tested-by: Theodore Ts'o <tytso at mit.edu> Cc: Neil Horman <nhorman

Commit 4490001029012539937ff02778fe6180613fa949 ("virtio-net: enable multiqueue by default") blindly set the affinity instead of queues during probe which can cause a mismatch of #queues between guest and host. This patch fixes it by setting queues. Reported-by: Theodore Ts'o <tytso at mit.edu> Tested-by: Theodore Ts'o <tytso at mit.edu> Cc: Neil Horman <nhorman

There's a new set of ext2/3 patches for 2.4.21-pre5 available at: http://thunk.org/tytso/linux/extfs-2.4-update/extfs-update-2.4.21pre5-2 and in broken out form at: http://thunk.org/tytso/linux/extfs-2.4-update/broken-out-2.4.21pre5-2 New to this patch set include: * A kludge to help htree work well with Linux's NFS implementation * Allow the orlov allocator to be disabled via a

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Hi there, Is there a utility to create an EXT3 file system image from directories? Just like the mkfs.jffs2 which creates a JFFS2 file system image from directories? The "mke2fs -j" only creates the bare bone file system, what I want is to build an image with pre-built content. Thanks, Debbie

https://bugzilla.samba.org/show_bug.cgi?id=11588 Bug ID: 11588 Summary: missing option: preallocate for all files except for sparse Product: rsync Version: 3.1.2 Hardware: x64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: core

On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > > There is a huge disadvantage to the fact that CPUID is a user space > instruction, though. But if the goal is to provide something like getrandom(2) direct from the Host OS, it's not necessarily harmful to allow the Guest ring 3 code to be able to fetch randomness in that way. The hypervisor can implement rate

On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > > There is a huge disadvantage to the fact that CPUID is a user space > instruction, though. But if the goal is to provide something like getrandom(2) direct from the Host OS, it's not necessarily harmful to allow the Guest ring 3 code to be able to fetch randomness in that way. The hypervisor can implement rate

I've backported all of the bugfixes to the 2.5 dxdir/htree patches to 2.4, and have created a new set of patches for Linux 2.4.21rc5. At this point it *looks* like we've fixed all of the htree bugs that people have reported, including the brelse bug, the memory leak bugs, and the NFS compatibility problems. I've done *very* light testing, and things seem to work, but I'm now

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote: > > It's head of my virtio-next tree. Hey Rusty, While we have your attention --- what's your opinion about adding TRIM support to virtio-blk. I understand that you're starting an OASIS standardization process for virtio --- what does that mean vis-a-vis a patch to plumb discard support through virtio-blk?

On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote: > > It's head of my virtio-next tree. Hey Rusty, While we have your attention --- what's your opinion about adding TRIM support to virtio-blk. I understand that you're starting an OASIS standardization process for virtio --- what does that mean vis-a-vis a patch to plumb discard support through virtio-blk?

On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o <tytso at mit.edu> wrote: > > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > >> > >> There is a huge disadvantage to the fact that CPUID is a user space > >> instruction, though. > > > > But if the goal is to

On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o <tytso at mit.edu> wrote: > > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > >> > >> There is a huge disadvantage to the fact that CPUID is a user space > >> instruction, though. > > > > But if the goal is to

On 09/19/2014 04:12 PM, Andy Lutomirski wrote: > > To force deterministic execution. > > I incorrectly thought that the kernel could switch RDRAND on and off. > It turns out that a hypervisor can do this, but not the kernel. Also, > determinism is lost anyway because of TSX, which *also* can't be > turned on and off. > Actually, a much bigger reason is because it