On Fri, 2014-06-27 at 12:08 +0300, Artem Bityutskiy wrote:
> To make 100% sure you'd not only need to drop VFS-level caches but also
> file-system-level caches. Indeed, file-systems have their own rather
Sorry, I wanted to say "rather complex" here
> buffers for different indexing data-structures,
On Fri, 2014-06-27 at 10:41 +0200, Matthias Schniedermeyer wrote:
> On 26.06.2014 13:57, Luká? Czerner wrote:
>
> > > So if the authors want to sell this new interface (in whatever form) to
> > > the kernel community, they should start with providing a solid use-case,
> > > with some more details,
a ,
> Alexander Viro , linux-fsde...@vger.kernel.org,
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] sysctl: Add a feature to drop caches selectively
>
> On 26.06.2014 13:57, Luká? Czerner wrote:
>
> > > So if the authors want to sell this new interfa
On 06/27/2014 04:55 AM, Dave Chinner wrote:
On Thu, Jun 26, 2014 at 02:10:28PM +0200, Bernd Schubert wrote:
On 06/26/2014 01:57 PM, Lukáš Czerner wrote:
On Thu, 26 Jun 2014, Artem Bityutskiy wrote:
On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:
On 06/26/2014 08:13 AM, Artem Bityutsk
On 26.06.2014 13:57, Luká? Czerner wrote:
> > So if the authors want to sell this new interface (in whatever form) to
> > the kernel community, they should start with providing a solid use-case,
> > with some more details, explore alternatives and show how the
> > alternatives do not work for them
On Thu, Jun 26, 2014 at 02:10:28PM +0200, Bernd Schubert wrote:
> On 06/26/2014 01:57 PM, Lukáš Czerner wrote:
> >On Thu, 26 Jun 2014, Artem Bityutskiy wrote:
> >>On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:
> >>>On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:
> On Thu, 2014-06-26 a
On Thu, Jun 26, 2014 at 09:13:19AM +0300, Artem Bityutskiy wrote:
> On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
> > Your particular use case can be handled by directing your benchmark
> > at a filesystem mount point and unmounting the filesystem in between
> > benchmark runs. There is n
On 06/26/2014 01:57 PM, Lukáš Czerner wrote:
On Thu, 26 Jun 2014, Artem Bityutskiy wrote:
On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:
On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:
On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
Your particular use case can be handled by
g,
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] sysctl: Add a feature to drop caches selectively
>
> On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:
> > On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:
> > > On Thu, 2014-06-26 at 11:06 +1000, Dave Chinn
On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:
> On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:
> > On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
> >> Your particular use case can be handled by directing your benchmark
> >> at a filesystem mount point and unmounting the filesyst
On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:
On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
Your particular use case can be handled by directing your benchmark
at a filesystem mount point and unmounting the filesystem in between
benchmark runs. There is no ned to adding kernel functio
> With a binary interface like an ioctl I can see how you could have extra
> unused fields which you can ignore now and let people start adding extra
> options like the range in the future.
Yes, ioctl is another possibility. But I would argue that sysctl is
more convenient interface, because idea
On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
> Your particular use case can be handled by directing your benchmark
> at a filesystem mount point and unmounting the filesystem in between
> benchmark runs. There is no ned to adding kernel functionality for
> somethign that can be so easily
On Wed, Jun 25, 2014 at 10:25:05AM +0200, Thomas Knauth wrote:
> On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy wrote:
> > Plus some explanations WRT why proc-based interface and what would be
> > the alternatives, what if tomorrow we want to extend the functionality
> > and drop caches only fo
On Wed 2014-06-25 10:25:05, Thomas Knauth wrote:
> On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy wrote:
> > Plus some explanations WRT why proc-based interface and what would be
> > the alternatives, what if tomorrow we want to extend the functionality
> > and drop caches only for certain file
On Wed, 2014-06-25 at 15:23 +0200, Thomas Knauth wrote:
> On Wed, Jun 25, 2014 at 11:56 AM, Artem Bityutskiy
> wrote:
> > Thanks for the answer, although you forgot to comment on the question
> > about possibly extending the new interface to work with file ranges in
> > the future. For example, I
On Wed, 2014-06-25 at 15:23 +0200, Thomas Knauth wrote:
> On Wed, Jun 25, 2014 at 11:56 AM, Artem Bityutskiy
> wrote:
> > Thanks for the answer, although you forgot to comment on the question
> > about possibly extending the new interface to work with file ranges in
> > the future. For example, I
On Wed, Jun 25, 2014 at 11:56 AM, Artem Bityutskiy wrote:
> Thanks for the answer, although you forgot to comment on the question
> about possibly extending the new interface to work with file ranges in
> the future. For example, I have a 2 TiB file, and I am only interested
> in dropping caches f
On Wed, Jun 25, 2014 at 12:03 PM, Artem Bityutskiy wrote:
> On Wed, 2014-06-25 at 10:25 +0200, Thomas Knauth wrote:
>> On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy
>> wrote:
>> > Plus some explanations WRT why proc-based interface and what would be
>> > the alternatives, what if tomorrow we
On Wed, Jun 25, 2014 at 2:20 PM, Alexey Dobriyan wrote:
>> +static void clean_all_dentries_locked(struct dentry *dentry)
>> +{
>> + struct dentry *child;
>> +
>> + list_for_each_entry(child, &dentry->d_subdirs, d_u.d_child) {
>> + clean_all_dentries_locked(child);
>> + }
>> +
>> + clean_mapping(de
On Wed, 2014-06-25 at 10:25 +0200, Thomas Knauth wrote:
> On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy wrote:
> > Plus some explanations WRT why proc-based interface and what would be
> > the alternatives, what if tomorrow we want to extend the functionality
> > and drop caches only for certa
On Wed, 2014-06-25 at 10:25 +0200, Thomas Knauth wrote:
> On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy wrote:
> > Plus some explanations WRT why proc-based interface and what would be
> > the alternatives, what if tomorrow we want to extend the functionality
> > and drop caches only for certa
On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy wrote:
> Plus some explanations WRT why proc-based interface and what would be
> the alternatives, what if tomorrow we want to extend the functionality
> and drop caches only for certain file range, is this only for regular
> files or also for dire
On Tue, 2014-06-24 at 14:59 -0700, David Rientjes wrote:
> On Tue, 24 Jun 2014, Maksym Planeta wrote:
>
> > To clean the page cache one can use /proc/sys/vm/drop_caches. But this
> > drops the whole page cache. In contrast to that sdrop_caches enables
> > ability to drop the page cache selectively
On Tue, 24 Jun 2014, Maksym Planeta wrote:
> To clean the page cache one can use /proc/sys/vm/drop_caches. But this
> drops the whole page cache. In contrast to that sdrop_caches enables
> ability to drop the page cache selectively by path string.
>
> Suggested-by: Thomas Knauth
> Signed-off-by:
25 matches
Mail list logo
