Re: [PATCH V3 1/6] stm class: Add ioctl get_options interface

[Alexander Shishkin]

Chunyan Zhang  writes:

> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.

I'm not sure I understand the reasoning behind this. If a userspace
program opens a communication channel and wants to configure certain
features on it, why does its choice depend on what has been configured
for this channel previously? It can be anything at all. Most likely,
it's either unconfigured or configured to its default values, but why
does this matter for a new writer?

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 1/3] rdmacg: Added rdma cgroup controller.

[Tejun Heo]

Hello, Parav.

On Fri, Feb 12, 2016 at 02:49:38AM +0530, Parav Pandit wrote:
> 1. Removed two type of resource pool, made is single type (as you
> described in past comment)
> 2. Removed match tokens and have array definition like "qp", "mr", "cq" etc.
> 3. Wrote small parser and avoided match_token API as that won't work
> due to different array definition
> 4. Removed one-off remove API to unconfigure cgroup, instead all
> resource should be set to max.
> 5. Removed resource pool type (user/default), instead having max_num_cnt,
> when ref_cnt drops to zero and max_num_cnt = total_rescource_cnt, pool is 
> freed.
> 6. Resource definition ownership is now only with IB stack at single
> header file, no longer in each low level driver.
> This goes through IB maintainer and other reviewers eyes.
> This continue to give flexibility to not force kernel upgrade for few
> enums additions for new resource type.
> 7. Wherever possible pool lock is pushed out, except for hierarchical
> charging/unchanging points, as it not possible to do so, due to
> iterative process involves blocking allocations of rpool. Coming up
> more levels up to release locks doesn't make any sense either.
> This is anyway slow path where rpool is not allocated. Except for
> typical first resource allocation, this is less traveled path.
> 8.Other minor cleanups.
> 9. Avoided %d manipulation due to removal of match_token and replaced
> with seq_putc etc friend functions.

Sounds great.  Can't tell too much without looking at the code tho.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: SubmittingPatches: Add note about Reviewed-by tags

[Markus Mayer]

For some odd reason, the first version of this e-mail had an HTML part
and got rejected from the lists. My apologies for the extra e-mail.

On 11 February 2016 at 18:12, Florian Fainelli  wrote:
> As is now common in a lot of organization having an internal code review
> process (be it through Gerritt or other tools), patches extracted from
> this review process and submitted to public mailing-lists will have
> pre-existing Reviewed-by tags. Add a note about why these tags exists,
> and what a maintainer could be doing with those. Some maintainers did
> complain before that these tags had to be added when the patches get
> submitted to the public, while some just ignored and took the patches
> as-is.
>
> Signed-off-by: Florian Fainelli 
> ---
>  Documentation/SubmittingPatches | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index d603fa078235..b1b8e39bc5ee 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -582,6 +582,14 @@ reviewers and to inform maintainers of the degree of 
> review which has been
>  done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
>  understand the subject area and to perform thorough reviews, will normally
>  increase the likelihood of your patch getting into the kernel.
> +The presence of Reviewed-by tags for an initial patch submission are 
> indicative
> +of an existing internal review process that may occur at various 
> organizations,
> +prior to a mainline kernel submission.  The presence of these tags can give 
> the
> +maintainer a good appreciation that somebody has done an internal review
> +following the same guidelines as those done on a public mailing-list.
> +Maintainers are encouraged to maintain these tags while accepting and merging
> +patches, appreciation of these pre-existing Revivewed-by tags is left are 
> their
> +own discretion.

Some nit-picking on the last sentence. How about:

While maintainers are encouraged to maintain these tags when accepting
and merging patches, appreciation of these pre-existing Reviewed-by
tags is left at their own discretion.

There's also a typo in "Reviewed-by" in the original sentence.

>  A Suggested-by: tag indicates that the patch idea is suggested by the person
>  named and ensures credit to the person for the idea. Please note that this
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/6] stm class: Add ioctl get_options interface

[Mathieu Poirier]

On 12 February 2016 at 08:18, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> There is already an interface of set_options, but no get_options yet.
>> Before setting any options, one would may want to see the current
>> status of that option by means of get_options interface. This
>> interface has been used in CoreSight STM driver.
>
> I'm not sure I understand the reasoning behind this. If a userspace
> program opens a communication channel and wants to configure certain
> features on it, why does its choice depend on what has been configured
> for this channel previously? It can be anything at all. Most likely,
> it's either unconfigured or configured to its default values, but why
> does this matter for a new writer?

A client may wish to change the settings (invariant/guaranteed) it has
on a specific channel - it may even want to so do multiple times.  The
idea behind introducing a get_options() was to probe the specific
settings of a channel before going a head with a new configuration.
In hindsight it may not be needed as a client should simply go ahead
and push down the configuration it wants.

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 12 February 2016 at 09:27, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> On 8 February 2016 at 06:26, Alexander Shishkin
>>  wrote:
>>> This $end==$start situation itself may be ambiguous and can be
>>> interpreted either as having just one *static* master ID fixed for all
>>> SW writers (what I assumed from your commit message) or as having a
>>> floating master ID, which changes of its own accord and is not
>>> controllable by software.
>>
>> Some clarification here.
>>
>> On ARM from a SW point of view $end == $start and that doesn't change
>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>> on other platforms where masterID configuration does change and is
>> important, the condition $end == $start could also be valid.
>
> Yes, that's what I was saying. The thing is, on the system-under-tracing
> side these two situations are not very different from one
> another. Master IDs are really just numbers without any semantics
> attached to them in the sense that they are not covered by the mipi spec
> or any other standard (to my knowledge).

We are definitely on the same page here, just using slightly different terms.

>
> The difference is in the way we map channels to masters. One way is to
> allocate a distinct set of channels for each master (the way Intel Trace
> Hub does it); another way is to share the same set of channels between
> multiple masters.

We are in total agreement.

> So we can describe this as "hardware implements the
> same set of channels across multiple masters" or something along those
> lines.

I suggest "Shared channels"?  In the end, that's really what it is...

The outstanding issue is still how to represent these to different way
of mapping things in the STM core.  I suggested a flag, called
"mstatic" (but that can be changed), and a representation of '-1' in
for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
I'd be fine with another mechanism.  What I am keen on is that from
sysFS users can quickly tell which heuristic is enacted on that
specific architecture.

>
> Actually, in the latter scheme of things you can also have multiple
> masters, at least theoretically. Say, you have masters [0..15], each
> with distinct set of channels, but depending on hardware state these
> masters actually end up as $state*16+$masterID in the STP stream.
>
> So we might also think about differentiating between the hardware
> masters (0 though 15 in the above example) and STP masters.

I'm not sure I get what you mean here.  On ARM the masterIDs assigned
in HW, which will depend on the state, will show up in the STP stream.
But again, I might be missing your point.

Thanks,
Mathieu

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] kernel: fs: drop_caches: add dds drop_caches_count

[Daniel Walker]

From: Khalid Mughal 

Currently there is no way to figure out the droppable pagecache size
from the meminfo output. The MemFree size can shrink during normal
system operation, when some of the memory pages get cached and is
reflected in "Cached" field. Similarly for file operations some of
the buffer memory gets cached and it is reflected in "Buffers" field.
The kernel automatically reclaims all this cached & buffered memory,
when it is needed elsewhere on the system. The only way to manually
reclaim this memory is by writing 1 to /proc/sys/vm/drop_caches. But
this can have performance impact. Since it discards cached objects,
it may cause high CPU & I/O utilization to recreate the dropped
objects during heavy system load.
This patch computes the droppable pagecache count, using same
algorithm as "vm/drop_caches". It is non-destructive and does not
drop any pages. Therefore it does not have any impact on system
performance. The computation does not include the size of
reclaimable slab.

Cc: xe-ker...@external.cisco.com
Cc: dave.han...@intel.com
Cc: han...@cmpxchg.org
Cc: r...@redhat.com
Signed-off-by: Khalid Mughal 
Signed-off-by: Daniel Walker 
---
 Documentation/sysctl/vm.txt | 12 +++
 fs/drop_caches.c| 80 +++--
 include/linux/mm.h  |  3 ++
 kernel/sysctl.c |  7 
 4 files changed, 100 insertions(+), 2 deletions(-)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 89a887c..13a501c 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -29,6 +29,7 @@ Currently, these files are in /proc/sys/vm:
 - dirty_ratio
 - dirty_writeback_centisecs
 - drop_caches
+- drop_caches_count
 - extfrag_threshold
 - hugepages_treat_as_movable
 - hugetlb_shm_group
@@ -224,6 +225,17 @@ with your system.  To disable them, echo 4 (bit 3) into 
drop_caches.
 
 ==
 
+drop_caches_count
+
+The amount of droppable pagecache (in kilobytes). Reading this file
+performs same calculation as writing 1 to /proc/sys/vm/drop_caches.
+The actual pages are not dropped during computation of this value.
+
+To read the value:
+   cat /proc/sys/vm/drop_caches_count
+
+==
+
 extfrag_threshold
 
 This parameter affects whether the kernel will compact memory or direct
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index d72d52b..0cb2186 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -8,12 +8,73 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "internal.h"
 
 /* A global variable is a bit ugly, but it keeps the code simple */
+
 int sysctl_drop_caches;
+unsigned int sysctl_drop_caches_count;
+
+static int is_page_droppable(struct page *page)
+{
+   struct address_space *mapping = page_mapping(page);
+
+   if (!mapping)
+   return 0;
+   if (PageDirty(page))
+   return 0;
+   if (PageWriteback(page))
+   return 0;
+   if (page_mapped(page))
+   return 0;
+   if (page->mapping != mapping)
+   return 0;
+   if (page_has_private(page))
+   return 0;
+   return 1;
+}
+
+static unsigned long count_unlocked_pages(struct address_space *mapping)
+{
+   struct pagevec pvec;
+   pgoff_t start = 0;
+   pgoff_t end = -1;
+   unsigned long count = 0;
+   int i;
+   int rc;
+
+   pagevec_init(, 0);
+   while (start <= end && pagevec_lookup(, mapping, start,
+   min(end - start, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
+   for (i = 0; i < pagevec_count(); i++) {
+   struct page *page = pvec.pages[i];
+   start = page->index;
+   if (start > end)
+   break;
+   if (!trylock_page(page))
+   continue;
+   WARN_ON(page->index != start);
+   rc = is_page_droppable(page);
+   unlock_page(page);
+   count += rc;
+   }
+   pagevec_release();
+   cond_resched();
+   start++;
+   }
+   return count;
+}
 
-static void drop_pagecache_sb(struct super_block *sb, void *unused)
+static void drop_pagecache_sb(struct super_block *sb, void *count)
 {
struct inode *inode, *toput_inode = NULL;
 
@@ -29,7 +90,11 @@ static void drop_pagecache_sb(struct super_block *sb, void 
*unused)
spin_unlock(>i_lock);
spin_unlock(>s_inode_list_lock);
 
-   invalidate_mapping_pages(inode->i_mapping, 0, -1);
+   if (count)
+   sysctl_drop_caches_count += 
count_unlocked_pages(inode->i_mapping);
+   

Re: [RFC] A first shot at asciidoc-based formatted docs

[Keith Packard]

Keith Packard  writes:

> The goal would be to create an html document which could be used without
> javascript, and that would work without css as well.

I've managed to hack up asciidoc to generate the TOC within the
document, rather than requiring javascript. The changes are fairly
minor, and seem to add a nice generalization to the asciidoc environment
which should be useful in other contexts.

The changes consist of two bits -- the first is to allow the diversion
of some text from .conf file sections, the second is to postpone some
attribute processing to a second pass over the document so that the TOC
can be inserted in the desired location, instead of requiring that it be
placed at the bottom.

I've sent these changes upstream, and also pushed them to a personal
asciidoc git repository at :

git clone git://keithp.com/git/asciidoc

-- 
-keith


signature.asc
Description: PGP signature