From: Konstantin Khlebnikov <khlebnikov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
To: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Sha Zhengju <handai.szj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH RFC] fsio: filesystem io accounting cgroup
Date: Tue, 09 Jul 2013 21:12:55 +0400 [thread overview]
Message-ID: <51DC4497.6060107@openvz.org> (raw)
In-Reply-To: <20130709153907.GA17972-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
Theodore Ts'o wrote:
> Another major problem with this concept is that it lumps all I/O's
> into a single cgroup. So I/O's from pseudo filesystems (such as
> reading from /sys/kernel/debug/tracing/trace_pipe), networked file
> systems such as NFS, and I/O to various different block devices all
> get counted in a single per-cgroup limit.
>
> This doesn't seem terribly useful to me. Network resources and block
> resources are quite different, and counting pseudo file systems and
> ram disks makes no sense at all.
Yep, I know it. I've already mentioned about this as first planned improvement:
|* Split bdi into several tiers and account them separately. For example:
| hdd/ssd/usb/nfs. In complicated containerized environments that might be
| different kinds of storages with different limits and billing. This is more
| usefull that independent per-disk accounting and much easier to implement
| because all per-tier structures are allocated before disk appearance.
Accounting each BDI separately doesn't very useful too, so I've chosen
something in the middle.
>
> Regards,
>
> - Ted
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo-Bw31MaZKKs0EbZ0PF+XxCw@public.gmane.org For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email:<a href=mailto:"dont-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"> email-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org</a>
WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Theodore Ts'o <tytso@mit.edu>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@suse.cz>,
cgroups@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Sha Zhengju <handai.szj@gmail.com>,
devel@openvz.org
Subject: Re: [PATCH RFC] fsio: filesystem io accounting cgroup
Date: Tue, 09 Jul 2013 21:12:55 +0400 [thread overview]
Message-ID: <51DC4497.6060107@openvz.org> (raw)
In-Reply-To: <20130709153907.GA17972@thunk.org>
Theodore Ts'o wrote:
> Another major problem with this concept is that it lumps all I/O's
> into a single cgroup. So I/O's from pseudo filesystems (such as
> reading from /sys/kernel/debug/tracing/trace_pipe), networked file
> systems such as NFS, and I/O to various different block devices all
> get counted in a single per-cgroup limit.
>
> This doesn't seem terribly useful to me. Network resources and block
> resources are quite different, and counting pseudo file systems and
> ram disks makes no sense at all.
Yep, I know it. I've already mentioned about this as first planned improvement:
|* Split bdi into several tiers and account them separately. For example:
| hdd/ssd/usb/nfs. In complicated containerized environments that might be
| different kinds of storages with different limits and billing. This is more
| usefull that independent per-disk accounting and much easier to implement
| because all per-tier structures are allocated before disk appearance.
Accounting each BDI separately doesn't very useful too, so I've chosen
something in the middle.
>
> Regards,
>
> - Ted
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email:<a href=mailto:"dont@kvack.org"> email@kvack.org</a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: "Theodore Ts'o" <tytso@mit.edu>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@suse.cz>,
cgroups@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Sha Zhengju <handai.szj@gmail.com>,
devel@openvz.org
Subject: Re: [PATCH RFC] fsio: filesystem io accounting cgroup
Date: Tue, 09 Jul 2013 21:12:55 +0400 [thread overview]
Message-ID: <51DC4497.6060107@openvz.org> (raw)
In-Reply-To: <20130709153907.GA17972@thunk.org>
Theodore Ts'o wrote:
> Another major problem with this concept is that it lumps all I/O's
> into a single cgroup. So I/O's from pseudo filesystems (such as
> reading from /sys/kernel/debug/tracing/trace_pipe), networked file
> systems such as NFS, and I/O to various different block devices all
> get counted in a single per-cgroup limit.
>
> This doesn't seem terribly useful to me. Network resources and block
> resources are quite different, and counting pseudo file systems and
> ram disks makes no sense at all.
Yep, I know it. I've already mentioned about this as first planned improvement:
|* Split bdi into several tiers and account them separately. For example:
| hdd/ssd/usb/nfs. In complicated containerized environments that might be
| different kinds of storages with different limits and billing. This is more
| usefull that independent per-disk accounting and much easier to implement
| because all per-tier structures are allocated before disk appearance.
Accounting each BDI separately doesn't very useful too, so I've chosen
something in the middle.
>
> Regards,
>
> - Ted
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email:<a href=mailto:"dont@kvack.org"> email@kvack.org</a>
next prev parent reply other threads:[~2013-07-09 17:12 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 10:01 [PATCH RFC] fsio: filesystem io accounting cgroup Konstantin Khlebnikov
2013-07-08 10:01 ` Konstantin Khlebnikov
2013-07-08 17:00 ` Tejun Heo
2013-07-08 17:00 ` Tejun Heo
2013-07-08 17:00 ` Tejun Heo
2013-07-08 17:52 ` Vivek Goyal
2013-07-08 17:52 ` Vivek Goyal
2013-07-08 17:56 ` Tejun Heo
2013-07-08 17:56 ` Tejun Heo
2013-07-09 8:28 ` Konstantin Khlebnikov
2013-07-09 8:28 ` Konstantin Khlebnikov
2013-07-09 12:57 ` Tejun Heo
2013-07-09 12:57 ` Tejun Heo
[not found] ` <20130709125734.GA2478-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-07-09 13:15 ` Konstantin Khlebnikov
2013-07-09 13:15 ` Konstantin Khlebnikov
2013-07-09 13:15 ` Konstantin Khlebnikov
2013-07-09 13:16 ` Tejun Heo
2013-07-09 13:16 ` Tejun Heo
2013-07-09 13:16 ` Tejun Heo
2013-07-09 13:16 ` Tejun Heo
2013-07-09 13:43 ` Konstantin Khlebnikov
2013-07-09 13:43 ` Konstantin Khlebnikov
2013-07-09 13:45 ` Tejun Heo
2013-07-09 13:45 ` Tejun Heo
2013-07-09 14:18 ` Vivek Goyal
2013-07-09 14:18 ` Vivek Goyal
2013-07-09 14:29 ` Tejun Heo
2013-07-09 14:29 ` Tejun Heo
2013-07-09 14:54 ` Vivek Goyal
2013-07-09 14:54 ` Vivek Goyal
2013-07-09 15:08 ` Tejun Heo
2013-07-09 15:08 ` Tejun Heo
[not found] ` <20130710030955.GA3569@redhat.com>
[not found] ` <20130710030955.GA3569-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-10 3:50 ` Tejun Heo
2013-07-10 3:50 ` Tejun Heo
2013-07-10 3:50 ` Tejun Heo
[not found] ` <20130709134558.GD2478-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-07-09 14:35 ` Konstantin Khlebnikov
2013-07-09 14:35 ` Konstantin Khlebnikov
2013-07-09 14:35 ` Konstantin Khlebnikov
2013-07-09 14:42 ` Tejun Heo
2013-07-09 14:42 ` Tejun Heo
2013-07-09 15:06 ` Vivek Goyal
2013-07-09 15:06 ` Vivek Goyal
2013-07-09 17:42 ` Konstantin Khlebnikov
2013-07-09 17:42 ` Konstantin Khlebnikov
2013-07-09 18:35 ` Vivek Goyal
2013-07-09 18:35 ` Vivek Goyal
2013-07-09 20:54 ` Konstantin Khlebnikov
2013-07-09 20:54 ` Konstantin Khlebnikov
2013-07-08 18:11 ` Vivek Goyal
2013-07-08 18:11 ` Vivek Goyal
2013-07-09 15:39 ` Theodore Ts'o
2013-07-09 15:39 ` Theodore Ts'o
[not found] ` <20130709153907.GA17972-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2013-07-09 17:12 ` Konstantin Khlebnikov [this message]
2013-07-09 17:12 ` Konstantin Khlebnikov
2013-07-09 17:12 ` Konstantin Khlebnikov
-- strict thread matches above, loose matches on Subject: below --
2013-07-08 9:59 Konstantin Khlebnikov
2013-07-08 9:59 ` Konstantin Khlebnikov
2013-07-10 4:43 ` Sha Zhengju
2013-07-10 4:43 ` Sha Zhengju
[not found] ` <CAFj3OHVtVGDnWHqNBRZH+LNtzDrbk8PO0fKLwFscZAWCJRW9oA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-10 6:03 ` Konstantin Khlebnikov
2013-07-10 6:03 ` Konstantin Khlebnikov
2013-07-10 6:03 ` Konstantin Khlebnikov
2013-07-10 8:37 ` Sha Zhengju
2013-07-10 8:37 ` Sha Zhengju
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=51DC4497.6060107@openvz.org \
--to=khlebnikov-gefaqzzx7r8dnm+yrofe0a@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=handai.szj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=tytso-3s7WtUTddSA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.