Andrew Morton <[EMAIL PROTECTED]> wrote:
> > The attached patch replaces backing_dev_info::memory_backed with
> > capabilitied bitmap.
>
> Looks sane to me, thanks.
>
> I hope you got all the conversions correct - breakage in the writeback
> dirty accounting manifests in subtle ways. I'll doubl
David Howells <[EMAIL PROTECTED]> wrote:
>
> The attached patch replaces backing_dev_info::memory_backed with capabilitied
> bitmap.
Looks sane to me, thanks.
I hope you got all the conversions correct - breakage in the writeback
dirty accounting manifests in subtle ways. I'll double-check it.
-
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > Sorry, yes. Obvious. Ugh. Andrew Morton suggested flipping the logic, and
> > although it was in conjunction with turning the concepts into bitfields, it
> > still stands here.
>
> OK, obviously Andrew has the final word in this. I just suggested
>
> Sorry, yes. Obvious. Ugh. Andrew Morton suggested flipping the logic, and
> although it was in conjunction with turning the concepts into bitfields, it
> still stands here.
OK, obviously Andrew has the final word in this. I just suggested
that it might be safer to have the logic flipped back.
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > It shouldn't silently break... It will refuse to compile. I renamed
> > "memory_backed" to "capabilities".
>
> This will silently break:
>
> static struct backing_dev_info my_bdi = {
>.ra_pages = MY_RA,
>.unplug_io_fn = default_unplug
> > Wouldn't it be better to reverse the meaning of BDI_CAP_ACCOUNT_DIRTY
> > and BDI_CAP_WRITEBACK_DIRTY (BDI_CAP_NO_ACCOUNT_DIRTY...)? That way
> > out of tree filesystems that implicitly zero bdi->memory_backed
> > wouldn't _silently_ break. E.g. fuse does this, though it would not
> > actuall
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > The attached patch replaces backing_dev_info::memory_backed with
> > capabilitied bitmap. The capabilities available include:
>
> Wouldn't it be better to reverse the meaning of BDI_CAP_ACCOUNT_DIRTY
> and BDI_CAP_WRITEBACK_DIRTY (BDI_CAP_NO_ACCOUNT_D
> The attached patch replaces backing_dev_info::memory_backed with
> capabilitied bitmap. The capabilities available include:
Wouldn't it be better to reverse the meaning of BDI_CAP_ACCOUNT_DIRTY
and BDI_CAP_WRITEBACK_DIRTY (BDI_CAP_NO_ACCOUNT_DIRTY...)? That way
out of tree filesystems that impl
The attached patch replaces backing_dev_info::memory_backed with capabilitied
bitmap. The capabilities available include:
(*) BDI_CAP_ACCOUNT_DIRTY
Set if the pages associated with this backing device should be tracked
by dirty page accounting.
(*) BDI_CAP_WRITEBACK_DIRTY
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Making it unsigned long on a 32-bit machine will make no
> > difference. Making it unsigned int on a 64-bit machine will waste four
> > bytes.
>
> No, it won't waste any bytes at all. It won't save any either.
>
> But if someone comes along later and
David Howells <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > Any particular reason? It's mixed in with other unsigned longs and
> > > pointers
> > > after all...
> >
> > Just that it's the natural wordsize of the machine, and uses less storage.
>
> Making it uns
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Any particular reason? It's mixed in with other unsigned longs and pointers
> > after all...
>
> Just that it's the natural wordsize of the machine, and uses less storage.
Making it unsigned long on a 32-bit machine will make no difference. Making it
David Howells <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > So I should fold the two other bitfields back into the capabilities mask
> > > and make it an unsigned long.
> >
> > I suppose so. Although unsigned int would be preferable.
>
> Any particular reason
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > So I should fold the two other bitfields back into the capabilities mask
> > and make it an unsigned long.
>
> I suppose so. Although unsigned int would be preferable.
Any particular reason? It's mixed in with other unsigned longs and pointers
afte
David Howells <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > Making these into bitfields would result in having to use three
> variables
> > > instead of just the one.
> >
> > Well let's do one or the other, and not have it half-and-half, please.
>
> So I
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Making these into bitfields would result in having to use three variables
> > instead of just the one.
>
> Well let's do one or the other, and not have it half-and-half, please.
So I should fold the two other bitfields back into the capabilities mas
David Howells <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > > +#define BDI_CAP_MAP_COPY0x0001 /* Copy can be mapped
> (MAP_PRIVATE) */
> > > +#define BDI_CAP_MAP_DIRECT 0x0002 /* Can be mapped
> directly (MAP_SHARED) */
> >
David Howells <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Yup. In this application the fields are initialised once (usually at
> > compile time) and are never modified.
>
> That's not exactly so. The block layer appears to modify them. See
> blk_queue_make_reque
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yup. In this application the fields are initialised once (usually at
> compile time) and are never modified.
That's not exactly so. The block layer appears to modify them. See
blk_queue_make_request() in ll_rw_blk.c.
David
-
To unsubscribe from this li
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > +#define BDI_CAP_MAP_COPY 0x0001 /* Copy can be mapped
> > (MAP_PRIVATE) */
> > +#define BDI_CAP_MAP_DIRECT 0x0002 /* Can be mapped directly
> > (MAP_SHARED) */
>
> Why not make these bitfields as well?
Because I want to copy
David Howells <[EMAIL PROTECTED]> wrote:
>
>
> The attached patch does two things:
>
> (1) It gets rid of backing_dev_info::memory_backed and replaces it with a
> pair of boolean values:
>
> (*) dirty_memory_acct
>
> True if the pages associated with this backing device sh
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2 Mar 2005, Andrew Morton wrote:
> >
> > Why not make these bitfields as well?
>
> Side note: bitfields aren't exactly wonderful.
Yup. In this application the fields are initialised once (usually at
compile time) and are never modified. So t
On Wed, 2 Mar 2005, Andrew Morton wrote:
>
> Why not make these bitfields as well?
Side note: bitfields aren't exactly wonderful. They tend to generate worse
code, and they make it much harder to work with combinations of flags
(both testing and initializing). They also have architecture-specifi
23 matches
Mail list logo
