All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] SLUB - define OO_ macro instead of hardcoded numbers
Date: Wed, 22 Oct 2008 22:30:55 +0400	[thread overview]
Message-ID: <20081022183055.GN9639@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0810221123150.17454@quilx.com>

[Christoph Lameter - Wed, Oct 22, 2008 at 11:24:58AM -0700]
> On Wed, 22 Oct 2008, Cyrill Gorcunov wrote:
>
>> [Christoph Lameter - Wed, Oct 22, 2008 at 11:10:56AM -0700]
>>> On Wed, 22 Oct 2008, Cyrill Gorcunov wrote:
>>>
>>>> +#define OO_SHIFT	16
>>>> +#define OO_MASK		((1 << OO_SHIFT) - 1)
>>>> +#define MAX_OBJS_PER_PAGE	65535 /* see struct page.objects */
>>>
>>> This is == OO_MASK right? Otherwise things will break when we change
>>> OO_SHIFT.
>>>
>>
>> Yes, I set it 65535 directly to distinguish it from OO_MASK
>> meaning not value and point to page.objects since they are
>> u16. Which meant that is the point where all limits start.
>> So it we set OO_SHIFT to say 14 it will not be a problem
>> but if we exceed 16 bits it will break SLUB. Am I right?
>> (I become scratching the head :)
>
> If you set it > 16 then the size of the field in struct page is violated.
>
> So
>
> #define MAX_OBJ_PER_PAGE MIN(1 << bits_in(page.objects) - 1, OO_MASK)
>
> ?
>
>

Looks really good for me (if it worth anything). But Christoph
doesn't OO_SHIT inspired by u16 too which means we could use
MAX_OBJ_PER_PAGE in form you mentoined but maybe we should define

#define OO_SHIFT bits_in(page.objects) to point out why we use
16 not 14, not 18 or whatever? How do you think?

		- Cyrill -

  reply	other threads:[~2008-10-22 18:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-22 16:18 [RFC] SLUB - define OO_ macro instead of hardcoded numbers Cyrill Gorcunov
2008-10-22 16:28 ` Christoph Lameter
2008-10-22 16:35   ` Cyrill Gorcunov
2008-10-22 16:53     ` Cyrill Gorcunov
2008-10-22 17:21       ` Cyrill Gorcunov
2008-10-22 17:47         ` Christoph Lameter
2008-10-22 17:50           ` Pekka Enberg
2008-10-22 17:58             ` Cyrill Gorcunov
2008-10-22 18:01               ` Pekka Enberg
2008-10-22 18:10               ` Christoph Lameter
2008-10-22 18:15                 ` Cyrill Gorcunov
2008-10-22 18:24                   ` Christoph Lameter
2008-10-22 18:30                     ` Cyrill Gorcunov [this message]
2008-10-22 18:45                       ` Christoph Lameter
2008-10-22 18:52                         ` Cyrill Gorcunov
2008-10-22 18:42                     ` Cyrill Gorcunov
2008-10-22 18:49                       ` Christoph Lameter
2008-10-22 18:53                         ` Cyrill Gorcunov
2008-10-22 18:03             ` Christoph Lameter
2008-10-22 17:54           ` Cyrill Gorcunov

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=20081022183055.GN9639@localhost \
    --to=gorcunov@gmail.com \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /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.