On Tue, Jul 07, 2015 at 11:32:56PM +0900, Sergey Senozhatsky wrote:
> On (07/07/15 22:36), Minchan Kim wrote:
> [..]
> > > struct zram *zram = dev_to_zram(dev);
> > > + struct zs_pool_stats pool_stats = {0};
> >
> > Does it work even if first member of the structure is non-scalar?
> > Personally I prefer memset for initliazation.
> > I believe modern compiler would optimize that quite well.
>
> zs_pool_stats contains only one member now, so I didn't bother.
>
> [..]
> > > struct zs_pool {
> > > - char *name;
> > > + char *name;
> >
> > huge tab?
> >
> > >
> > > - struct size_class **size_class;
> > > - struct kmem_cache *handle_cachep;
> > > + struct size_class **size_class;
> > > + struct kmem_cache *handle_cachep;
> >
> > tab?
> > tab?
> >
> > >
> > > - gfp_t flags; /* allocation flags used when growing pool */
> > > - atomic_long_t pages_allocated;
> >
> > Why changes comment position?
>
> Because otherwise it breaks 80-cols rule.
>
> > > + /* Allocation flags used when growing pool */
> > > + gfp_t flags;
> > > + atomic_long_t pages_allocated;
> > >
> >
> > Why blank line?
>
> To make it more readable? Separating logically different
> struct members. That's why the original code contains blank
> lines between `char *name' and `struct size_class **size_class;
> struct kmem_cache *handle_cachep;` and so on.
>
> I see no issue.
>
Okay, I am not against aboves you mentioned.
But please don't squeeze cleanup patch into core patchset from next time.
It really hate to review and make confused git-blame.
>
> > > + struct zs_pool_stats stats;
> > > #ifdef CONFIG_ZSMALLOC_STAT
> > > - struct dentry *stat_dentry;
> > > + struct dentry *stat_dentry;
> >
> > Tab.
>
> Well, I see no issue with aligned struct members. Looks less
> hairy and less messy than the original one.
But this is that I'm strongly against with you.
It depends on the person coding style.
I have been used white space.
As well, when I look at current code under mm which I'm getting used,
almost everything use just white space.
>
> clean:
>
> struct zs_pool {
> char *name;
>
> struct size_class **size_class;
> struct kmem_cache *handle_cachep;
>
> /* Allocation flags used when growing pool */
> gfp_t flags;
> atomic_long_t pages_allocated;
>
> struct zs_pool_stats stats;
>
> /* Compact classes */
> struct shrinker shrinker;
> bool shrinker_enabled;
> #ifdef CONFIG_ZSMALLOC_STAT
> struct dentry *stat_dentry;
> #endif
> };
>
>
>
> dirty:
Never dirty. It's more readable.
>
> struct zs_pool {
> char *name;
>
> struct size_class **size_class;
> struct kmem_cache *handle_cachep;
>
> gfp_t flags; /* allocation flags used when growing pool */
> atomic_long_t pages_allocated;
>
> #ifdef CONFIG_ZSMALLOC_STAT
> struct dentry *stat_dentry;
> #endif
> };
>
> -ss
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
