mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vladimir Saveliev <vs@namesys.com>
To: Andi Kleen <ak@suse.de>
Cc: Hans Reiser <reiser@namesys.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	reiserfs-list@namesys.com, Andrew Morton <akpm@osdl.org>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: reiser4 merging action list
Date: Tue, 28 Jun 2005 12:37:11 +0400	[thread overview]
Message-ID: <1119947829.3495.25.camel@tribesman.namesys.com> (raw)
In-Reply-To: <p73vf3zuqzq.fsf@verdi.suse.de>

Hello

On Tue, 2005-06-28 at 06:58, Andi Kleen wrote:
> Hans Reiser <reiser@namesys.com> writes:
> 
> >    * metafiles should be disabled until we can present code that works
> > right.  Half the list thinks we cannot solve the cycles problem ever. 
> > Disable metafiles and postpone problem until working code, or the
> > failure to produce it, makes it possible to do more than rant at each
> > other.  This is currently already done in the -mm patches, but is
> > mentioned lest someone think it forgotten.
> > 
> >    * update the locking documentation
> > 
> > Probably I forget something.
> 
> These are all big picture issues, but I think some low level attention to
> the individual code is still needed.
> 
> Some stuff that stood out from a very quick look:
> 
> I would like for the custom spin lock debugging (spin_macros.h) and
> profiling code to be removed (prof.[ch], spinprof.[ch]). Such code shouldn't 
> be in specific subsystems. 
> 
sorry, Andi, I guess you are looking at something old. Reiser4 does not
have neither prof.[ch], nor spinprof.[ch] and we removed already some
debugging code from spin_macros.h.

> The division functions in lib.h are useless IMHO, both callers seem
> to use divide by a power of two. And gcc supports shift in 64bit
> fine in the kernel. Can you remove that please? 
> 
ok

> statcnt.h: This is completely useless because you don't align
> the individual fields for cache lines - so you will still
> have false sharing everywhere. Also using NR_CPUS is nasty
> because it can be very big - num_possible_cpus() is better. 
> It should use the new dynamic per cpu allocator.
> 
statcnt.h is already removed.

> Best you just remove it for now and use atomic_t and readd properly
> when you do real SMP tuning with measurements.
> 
> debug.[ch]: A lot of these functions like "schedulable" are name space
> space polluting. 
> reiser4_kmalloc() such wrappers are deprecated. Please remove.
ok
> xmemset et.al should be replaced with the normal functions everywhere
> 
done.

> Best would be probably to remove most of these files for submission.
> 
> What is reiser4_internal? Can't you just use static like
> everybody else?

ok

> status_flags.c: Please remove that CONFIG_FRAME_POINTER code.
> In general i think it would be better if you removed that 
> "private mini crashdumping".

ok

> 
> Is there any reason you can't just use wait queues like everybody
> else instead of these reimplemented condition variables in kcond.[ch]?
> 
I will investigate that

> In general it would be good if someone experienced not from the reiser team
> would read the whole source and looks for obvious problems
> (I didn't, just mentioning stuff I from a quick look at some support
> files) 
> 
> -Andi
> 
> 


  reply	other threads:[~2005-06-28  8:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42BB7B32.4010100@slaphack.com.suse.lists.linux.kernel>
     [not found] ` <200506240334.j5O3YowB008100@laptop11.inf.utfsm.cl.suse.lists.linux.kernel>
     [not found]   ` <20050627092138.GD11013@nysv.org.suse.lists.linux.kernel>
     [not found]     ` <20050627124255.GB6280@thunk.org.suse.lists.linux.kernel>
     [not found]       ` <42C0578F.7030608@namesys.com.suse.lists.linux.kernel>
     [not found]         ` <20050627212628.GB27805@thunk.org.suse.lists.linux.kernel>
     [not found]           ` <42C084F1.70607@namesys.com.suse.lists.linux.kernel>
2005-06-28  2:58             ` Andi Kleen
2005-06-28  8:37               ` Vladimir Saveliev [this message]
2005-06-28  9:11                 ` Andi Kleen
2005-06-28  9:16                   ` Artem B. Bityuckiy
2005-06-24  3:17 reiser4 plugins David Masover
2005-06-24  3:34 ` Horst von Brand
2005-06-27  9:21   ` Markus   Törnqvist
2005-06-27 12:42     ` Theodore Ts'o
2005-06-27 19:46       ` Hans Reiser
2005-06-27 21:26         ` Theodore Ts'o
2005-06-27 23:00           ` reiser4 merging action list Hans Reiser
2005-06-27 23:23             ` Andrew Morton
2005-06-29  5:41               ` Hans Reiser
2005-06-29  6:18                 ` Pekka Enberg
2005-06-29 22:59                   ` Hans Reiser
2005-06-28  9:41             ` Christoph Hellwig
2005-06-28  9:48             ` Adrian Bunk

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=1119947829.3495.25.camel@tribesman.namesys.com \
    --to=vs@namesys.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome